Question of Trust: Funds Gone, or Chance Left?

There is a special category of entrepreneurs among those who approach our development company. These are clients who come with unfinished projects, having undergone highly negative experiences with their previous developers.

Having participated in the rescue of numerous such projects, I have some advice to share. In this article, I will outline the typical scenario that plays out in such instances, using a particular project as an example. Furthermore, I will showcase how the startup's co-founders could have avoided a significant portion of the adversities they endured due to the unfortunate selection of their initial developers.

Startup With a Tight Budget

This story follows the journey of seven ambitious individuals from Australia, who band together to pursue a captivating business idea. Their goal is to develop an app that can address a local currency exchange problem.

The situation is that Australia is surrounded by the islands of Oceania, where several dozen small island nations each maintain their own currency. The lives of the residents of these countries are closely interconnected. Australians and islanders frequently move between islands and often face challenges with currency exchange. The idea of our heroes was to address this issue through a unique social network. Within it, a traveler departing from Fiji, with no further use for Fijian dollars, could potentially negotiate with a traveler who has just arrived on the same island.

With only their savings to rely on, the aspiring entrepreneurs commenced their search for developers willing to take on the project within their constrained budget. And soon they found such a team. Upon discussing the project details, the developers requested full prepayment and set a deadline for delivering the finished application.

Things Go Wrong

As the agreed-upon deadline approached, it became clear that the application was nowhere near completion. What followed was an exhaustive and frustrating series of negotiations. The developers offered new excuses, made promises, and continually extended the deadlines. After two years since the project's inception, the entrepreneurs finally gave up hope of the developers fulfilling their responsibilities. Consequently, they made the decision to switch developers and eventually found their way to our company.

Back on Track

There they were, all seven of them, on my monitor screen - worn out, tense, and extremely angry. They knew the news wouldn't be great, but they certainly didn't anticipate it being this dire. As I launched the app, I had no choice but to deliver the harsh message: "Guys, you have nothing at all." The application consisted of a few screens with decorative buttons that were non-functional, lacking any actual code behind them.

This revelation, to put it mildly, didn't brighten their mood. It was clear that these individuals had been dealt a significant blow, as their expectations of having at least a partially completed application were utterly shattered. Nevertheless, they showed admirable strength in accepting the situation. Their determination to fight for their project left me truly impressed.

As we began the work, the initial weeks were charged with intensity. The clients closely scrutinized each of my moves and actions. Daily communication became routine, and they analyzed every word I spoke with suspicion. When I estimated that a particular task would take four days, they immediately questioned the timeline. However, I was ready for their scrutiny. We began with smaller tasks, and I provided detailed explanations for the time required for each step. As the application evolved day by day, new functionalities emerged. Witnessing the progress, the clients gradually relaxed and started to trust me more.

I managed to convince them to concentrate completely on three key functionalities, leaving out all other elements from the current agenda. These three primary screens constituted the core of the application. On the first screen, users could create a listing, by inputting their location, desired currency, and exchange amount. The second screen featured a search function to help users explore listings created by others and discover suitable options. Lastly, the third screen served as a space for negotiations, allowing two users to communicate and finalize all necessary details for an exchange.

Within just two months, these screens were ready, and the application was released, quickly gaining an active user following. The clients were genuinely in awe - a fully functional app created in just two months! Their happiness was palpable, and they expressed their gratitude with moving words. Even now, the memories of that day stir emotions within me. Moments like these, where I can see the real impact of my work and feel the clients' appreciation, hold tremendous value for me, especially in projects where forging strong client relationships was not straightforward.

Later on, there were several rounds of refining the application, each taking a couple of weeks. Eventually, my part in this journey concluded.

What This Story Reveals

This story highlights the flaws in the common tactics on how to hire an app developer commonly used by startup founders. Let's contemplate on them.

At what specific moment did the heroes of our story make a fatal mistake? Was there a chance for them to prevent such an adverse course of events?

I believe this misfortune to be a consequence of two missteps.

Signing a Contract Doesn't Mean All Concerns Are Behind You

I'm not aware of the details, but the entrepreneurs have likely taken all the usual steps in assessing the qualifications and reputation of their initial developers before hiring - like reviewing portfolios, reading testimonials, and conducting interviews.

Lacking technical expertise and being tight on budget, they made the wrong choice; and I think there was hardly anything they could do about it. There is no way to guarantee someone from hiring unreliable vendors. In my opinion, it wasn't this mistake that played a fatal role in this story, but rather their next step.

When the choice was made, they placed all their trust in vendors as if the act of signing the contract erased all doubts. They agreed to pay in full upfront and then disappeared for months, secure in the belief that they would return to find a ready-to-launch app.

Yet, there is never a guarantee that the chosen team will deliver as expected. One would better be prepared and take precautions:

• If entrepreneurs were paying in small parts, they wouldn't risk losing their entire budget at once.
• If they had regularly monitored the project's progress, they would have right away noticed it stalled.

Here's my key piece of advice - treat the initial weeks of collaboration as a testing phase.

It involves having regular meetings with the developers and requesting demonstrations of the progress achieved during those meetings. In my opinion, these meetings should occur at least once a week.

Furthermore, these meetings are crucial not only for monitoring developers' work but also for yielding significantly better results. Regardless of how thorough the initial idea is, during the development process, numerous unanticipated details will emerge. By holding regular meetings, developers have the chance to clarify these points, and clients can promptly notice any deviations arising from ambiguous task formulation or misunderstandings.

Persisting With Unreliable Developers Won't Save Your Investments; Instead, the Losses Will Multiply

Despite developers repeatedly failing to fulfill their promises, our heroes continued to hope for the best. It translated into two years wasted and emotional hardship endured by them.

If project problems don't improve for a few weeks, it's much better to face the reality and take prompt action to change developers.

How Can You Keep a Software Vendor in Check:

1. Negotiate manageable, monthly payments with developers.
2. Agree on weekly meetings with developers for progress tracking.
3. In initial weeks, monitor project progress closely.
4. If progress stalls, promptly consider switching developers.

While this tactic may not guarantee a problem-free experience, it reduces risks and losses to the best extent possible.