Out with the Old Developers, In with the New Developers

Within the next week, a project I’ve been working on for the past eight months will launch. Connect A Book is finally, triumphantly, excitedly coming… soon. Very soon.

So soon in fact it is already online but there are a few lingering bugs that still need to be squashed so I am holding off on the tremendous convenience of a direct link until that happens.

That CAB’s even at this stage, at a place where I can futz with it so much that I uncover bugs, click around, tweak copy, and, most importantly, *connect* *books*… is astonishing. Not because the technology to create a site like this is so advanced, because it’s not. Rather, it’s surprising that we’re here at all given how disastrous the first six months of developments was.

So, on the eve of the week that Connect A Book becomes fully operational, I am taking a look back at the timeline, progression and communication with the first team to see why that collaboration didn’t work out.

On November 20th, 2014, I signed a contract with two American developers to create Connect A Book, a book connection social network. The original delivery date was set at December 23rd, 2014.

On May 1st, 2015, more than four months after the project should’ve been completed, it became clear to me that the project wasn’t going anywhere in their hands. The developers had blown past deadlines they’d set for themselves, admitted mistakes in managing their company, and offered me a full refund twice in two months.

After the second offer, I decided to take them up on the refund, erasing all the progress that had been made and putting the project’s future in jeopardy.

For those interested in Connect A Book’s prolonged development, read on as I make sense of six months of lost time, missed cues, and potential turning points.

Love At First Site

I’ve had many websites. Some for webcomics, some for video portfolios, some for blogs. Up until November, I got by using hacked-together templates of WordPress or tinkering with Dreamweaver. A site with the functionality that Connect A Book required would certainly be out of my limited ability, so I posted the project on freelance portal eLance to attract developers. As a result, I received proposals from around the world, from India and Bulgaria to China and America. After conversations with nearly 20 developers, I settled on a team of two Americans because of their stated understanding of the project, their confidence in a delivery schedule, and the professional Statement of Work and contract they prepared.

Instead of an hourly rate, we agreed to a range of costs, based on their estimates of the time required to complete each task. The range quoted to me varied by a few thousand dollars, but would not eclipse the high end. It was  to be paid over three installments: one to start the project, one at the halfway point, and one upon completion. So with a signed contract and a wire transfer confirmation slip, we broke ground on Connect A Book.

Development Begins – Late November

One of our very first Skype calls is pushed half a week. Considering the first timeline was a month from start to finish, that’s significant. When the call did happen, the wireframes (basically the site’s skeleton, developed beforehand so both parties know they’re on the same page) didn’t exist. The developers felt it’d be better to jump straight to the first prototype.

I loved the gung-ho attitude, and everything felt so new and productive that I didn’t mind adjusting on the fly. Later, I received a well thought-out email regarding ISBN book identifiers, and how much control users should have in inputting their own books. Clearly, this team gets the project.

Development … is Delayed

I had planned a trip to leave December 24th, so the initial idea of having a functional site before I left was very tempting. I’d be able to return from the trip in January and charge full-steam ahead with marketing and user acquisition.

Then… some issues. They asked for an extension just before the holiday, along with the final payment “to keep the lights on.” I obliged, in the spirit of good holiday tidings and what I thought was solid progress. Maybe I wasn’t worried because I knew that development was fraught with elusive deadlines, and this was part of the experience. Maybe I was just more focused on my trip.

Development … is Delayed Again

Come January 27th (a month after initial project deadline), I receive a PDF detailing their request for a two-week extension. At the time, that seemed fine, because it seemed real. I could pin a new launch date on the Connect A Book project. A mid-February release! That’s exciting! The developers ask about my plans for marketing and testing with users. Having this conversation makes me feel like progress is being made.

Then…

February 4th. They had hired on an intern to work on the backend development, with the idea that if the intern doesn’t prove capable, then their main backed programmer will handle the fixes. The intern did not prove capable, and their plan did not work out. They requested an extension to March 4th. I was an intern. Is that why I’m not more frustrated?

February 26th. They mention they’ve hired on an outside development consultant. I wonder why I wasn’t consulted about hiring an outside development consultant. I understand that projects are subcontracted, but it’s different when the team is pitched to you one way, and then it seems like maybe they’re not capable of doing what they promised. If it speeds it up, I tell myself, then I shouldn’t have any reason to worry. Besides, we’re only a week away!

March 2nd. Is it ready!? No. Their outside development consultant hasn’t contacted them in five days. My main contact hopes I’m not too frustrated, and asks me to remember the sunny times we felt back together in December. Maybe I should’ve taken a cue from Taylor Swift.

March 4th. Speaking of December… they heard back from the consultant, looked at his work, and found it so unusable that they have to pick up where they left off in December. This is when I began to get confused, as the intern didn’t start working / irreversibly damaging the project until February. Shouldn’t they just have to go back to that build?

They hope to have a launchable product by April 5th. As frustrated as I am, I find solace in the delay. In late February I began taking a Product Management class through General Assembly, and the longer the project takes to go live, the more I can apply what I learn through the class about entrepreneurship and development.

Development Begins… Again!

March 26th. I receive a revised amendment for the Statement of Work, suggesting a few April iterations, and a May 1st release. I ask for a revision that allows me to request a refund.

April 3rd. An e-mail that includes this update: “Roadblocks we are facing: None at this time.”

April 17th. “Roadblocks we are facing: None at this time.” So, I haven’t seen any functioning updates on the site. No sprints with workable prototypes. Just… e-mails. And documents. And…

April 30th. The eve of the release! How to celebrate? With an e-mail… asking for a two-week extension?

May 1st. The rescheduled release day is here and the developers believe they are “more than halfway completed” but “not feeling confident this is going to be ready to deliver before May 15.”

They are also “prepared to honor the refund.”

I, perhaps stubbornly, propose that they move forward, but that with each week they don’t deliver the project, they give back 1/6th of the refund.

You Can’t Spell Refund Without ‘Fun’!

May 4th. They don’t love this idea. They suggest I either extend the timeline, allowing them to see the project through, or ask for the full refund. I am concerned with the number of times they’ve offered a full refund. This has already proven to be a money-losing venture for them. There can’t be any motivation on their end to keep going. Or maybe they just can’t do a part of the project, and are unwilling to admit that.

I ask for the refund.

May 11th. A week without a response. I follow up with a note about my legal counsel, and he says by May 18th, he’ll have an ETA on the refund.

May 18th. He’s “waiting on a few things.”

May 29th. I ask for the payment by the end of June.

June 6th. A promise of weekly updates with the refund’s progress, even if news is minimal.

These updates don’t come.

This is the End

July 1st – They write to say their company is failing and acknowledge the likelihood of legal action. I’m given access to the code they’ve created for Connect A Book, and I haven’t heard from them since.


I’m disappointed with the loss of this first investment in the project. While I haven’t pursued legal action yet, it’s a distinct possibility. Instead, I used the portion of the development budget I’d set aside for marketing, and hired a new team.

In late May, I reposted the project and fielded new offers. I heard from new developers, called references, and agreed to terms with a Ukrainian team.

Their process includes weekly sprints, daily Slack sessions, frequent e-mails, and close collaboration, making the development experience a dream. Working like this has kept me connected and it’s leading to the reality of a functioning Connect A Book.


For me, the biggest takeaways in dealing with a remote team are the following:

1. Constant Communication – The more the better, and over as many services as possible. Skype to establish a relationship. Slack to keep files in the same place and be able to work asynchronously. E-mail for the important stuff.

2. Weekly Payment -Tracking tasks and hours and paying weekly keeps the freelancing team honest in their work and keeps the founder aware of the project’s progress. Paying in larger installments inhibits that intimacy.

3. Regular Deliveries – Have a weekly or bi-weekly sprint system that allows features to be implemented, tested, and approved. Don’t allow time to pass without seeing new versions of the product. If that time is passing, withhold payment.

4. My Own Naiveté – I let the excitement of a team working on a project of mine overshadow the tangible results of that project. Instead of holding them to the standards of their own contract, I gave up leverage by paying before the project was completed. I let myself be distracted by the project’s future potential, rather than worrying myself with the development realities.

My hope in writing out this timeline is not to air dirty laundry but to understand better where I could’ve taken control of this project by taking a hard look at the details. I lost a good deal of time and money through my own inexperience and though Connect A Book’s delays were not entirely of my own doing, I bear the majority of the responsibility.

For those of you considering a project of your own, understand that the portrait I’ve painted of my experience is based on a very small sample size, and tinted with the errors of my ways, but hopefully the resulting picture is helpful to you. Know that coming through the process and seeing this project realized has been one of the most rewarding processes I’ve ever experienced, and I have found it all worthwhile.

After eight months, I can finally, triumphantly, excitedly say that Connect A Book is coming soon.

Very soon.

 

You may also like

Leave a Reply

Your email address will not be published. Required fields are marked *