166840283

One of the first decisions my co-founder Paul and I had to make when starting our company, after the all-important matte vs. glossy finish business card debate, was whether to build the site ourselves.

This wasn’t a trivial question. When we left our corporate jobs neither of us had built a Web application before. We had saved money to pay someone to build a site for us, which would have saved us time and resulted in a more polished product. Alternatively, we could have learned the skills necessary to build it ourselves, an approach that takes more time but saves money and ultimately allows a team to be self-sufficient.

At first we didn’t give too much consideration to the notion that we could build Treatings without outside help. But, after being warned repeatedly by founders who’d wasted precious time and money outsourcing early prototypes, we decided to build the site ourselves. In hindsight, this was the right decision.

Although he had never developed a Web application, Paul had an academic and professional background in computer science, so he jumped into the role of CTO. The first challenge for us was to settle on what to build, which involved defining our objectives, prioritizing features accordingly and mapping out the overall user experience. Once we’d established what to build, Paul began the process of figuring out how to build it. We anticipated that our biggest challenges would be technological, but they’ve turned out to be social.

As we’ve iterated on our professional networking platform, determining the best framework to help professionals propose coffee meetings with individuals to learn about companies/skills of interest, we’ve made a lot of mistakes. A lot of our gaffes and incorrect assumptions were only realized after releasing a series of prototypes that people could interact with. It didn’t matter that the products were unpolished. They were instrumental in shaping the framework as it stands today. We realized that the search for product/market fit takes time and lots of conversations with users. Paying someone else to build our early prototypes would have been an efficient way to waste money because many of our initial hypotheses were proved incorrect, rendering our makeshift code useless.

This summer, in preparation for onboarding our first paying customers, we decided to work with an outside developer on a freelance basis. We figured that we needed an expert to review our codebase, implement some testing to better identify bugs and optimize our site for a mobile browser before asking companies to open their checkbooks. Unfortunately, what was supposed to be a three week project is closing in on a three month project.

Prior to Treatings, I’d never hired or managed anyone before. In determining the best way to work with a freelancer, I could only reflect on management styles that I work well under. In my prior job as a junior investment banker, I did my best work when parameters for success were clearly defined but I was given the freedom to find the best way to achieve the agreed-upon goals. I brought that same mindset to working with the freelancer — we defined the scope of the project, he laid out a timeline and we gave him complete autonomy to work within the expected three week time period.

Working with the freelancer has cost us a lot of time, but we have no one to blame but ourselves. After months of building our own prototypes, we finally had someone helping us who had over a decade of experience building web applications. While we should have viewed him as a crutch, leaning on him to help us with issues like scalability that we had never dealt with, he effectively turned into a wheelchair. We were wary of getting in his way as he made changes in the codebase, and the longer the project went on the more paralyzed we became. It was as if our technical muscles had atrophied. When users would relay feedback or potential customers asked when they could test the platform, we would reply that we were held up on this project and our hands were effectively tied until it was over.

Relying wholly on a third party isn’t ideal in any situation, but it’s especially damaging when it is someone who is juggling multiple projects. Even if we were the only project the freelancer was working on, there’s an inevitable chasm between our obsession with Treatings and his. At week three of the project, when it was supposed to be completed, it was apparent that the timeline was stretched indefinitely. We did little about it. I felt privileged to have an expert working with us and didn’t want to micromanage him.

Although we offered to meet in-person and be helpful where we could to accelerate the project, overall we were too hands-off. We should have politely cut short the project when the first deadline was passed, but at that point we were incapacitated. While there are multiple other ways we should’ve handled the project differently, it’s likely the whole thing was premature.

In Geoffrey Moore’s book, “Crossing the Chasm,” he explains that “the point of greatest peril in the development of a high-tech market lies in making the transition from an early market dominated by a few visionary customers to a mainstream market dominated by a large block of customers who are predominantly pragmatists in orientation.” We may have put the cart before the horse, working with a freelancer in order to bolster technology that the mainstream market will care a lot more about than the early adopters we need to be focused on now. In reality, we don’t have so much traffic to make scalability a pressing concern.

We have to get those first few customers who are willing to pay for Treatings in spite of bugs. We were too quick to bring on an expert, subconsciously trying to put time and technology in-between us and our come-to-jesus moment of asking companies to open their checkbooks. We should have delayed this project until after we had revenue coming in the door, even if just a little. Being self-reliant leaves all accountability with the founding team, because it’s too easy to blame someone else for missed deadlines or product failings. If potential customers are resistant to fork over money because of minor technical bugs, it could be a red flag that we aren’t solving a dire enough problem.

This past week we decided that now was an appropriate time to end the project. Paul is tying together loose ends and we plan to push the site changes live next week. Then, we’ll work to get back into a process of continuous and incremental development and deployment. We’ve had good experiences working with freelancers on other aspects of the site, I just think it was jumping the gun to work with an expert developer at this stage.

For anyone still reading this post: Please hold us accountable for returning to self-sufficiency by giving us grief if the site is still not optimized for mobile by next Sunday.

By “grief,” I mean “the names of three freelance Ruby on Rails developers.”

This is the 14th installment of a PandoDaily weekly series that chronicles the experiences of a young entrepreneur as he bootstraps his startup.

Part 1, “The less-than-glamorous life of a young entrepreneur.”

Part 2, “How to survive co-founding a company with a friend.”

Part 3, “Starting a company and having a girlfriend isn’t easy.”

Part 4, “Customer validation: from lean startup to craigslist.”

Part 5, “Dealing with competitors without turning your product into Mr. Tumnus.” 

Part 6, “Why I gave up a cushy career as an investment banker to launch a startup.”

Part 7, “The best way to take feedback: Keep quiet.

Part 8, “The embarrassment of premature VC-infatuation.

Part 9, “Don’t ask me about money! I’m a startup founder.”

Part 10, “How a summer job selling knives helped me with my startup.”

Part 11, “When social norms interfere with your startup.”

Part 12, “It’s hard to tell which startups are simply spinning their wheels.”

Part 13, “What do you tell people who ask how your startup is doing?”

Come back next Sunday to read the next installment.

[Image courtesy: Thinkstock]