• Breaking News

    Thursday, December 7, 2017

    Startups The Perils of Outsourcing Your MVP

    Startups The Perils of Outsourcing Your MVP


    The Perils of Outsourcing Your MVP

    Posted: 06 Dec 2017 06:48 AM PST

    A few months ago, I had a brilliant idea for a website. Then, I had an even brillianter idea: build the website, but outsource all the work.

    Every great website starts with an MVP: the minimum viable product. It demonstrates the idea in its simplest form to test whether anyone is interested. When Twitter launched their MVP, you could only tweet pictures of Russet potatoes. Slack famously launched with language support limited to pig latin. Netflix is now so synonymous with instant streaming that you may have forgotten its first version, which required you to select a movie, then wait several days until Reed Hastings arrived at your house to act out the plot himself.

    I had a simple plan to build my MVP:

    1. Write a quick design specification.
    2. Find a rock star freelance developer with 10 years of experience in whichever web framework is the trendiest and most bleeding-edge.
    3. Offer said freelancer $4/hr so that I can maximize site profits.
    4. Watch the MVP blossom into a thriving web property frequented by millions of passionate users demanding that I take their money.

    You may be surprised to learn that this plan did not work. I'm not writing this from my luxurious $200 million Silicon Valley two-bedroom apartment. I didn't grab headlines with an outrageous buyout from Facebook. Instead, I'm writing this from my regular one-bedroom apartment after receiving a half-finished product and somehow becoming my freelancer's freelancer.

    The idea

    I follow the keto diet and like trying new recipes. There are plenty of good ones online, but they're spread across dozens of blogs, each with a different structure. These blogs tend to be slow and hard to navigate because keto bloggers rarely have experience with web development.

    My idea was a keto recipe directory. It would aggregate recipes from across the web into one easy-to-use website.

    Initial sketch of site

    Finding a freelancer

    Most of the site's heavy lifting was web scraping -- crawling recipe blogs and pulling out the relevant data. This is a common job on freelance developer sites like Upwork or Fiverr. I could probably find someone for a low price, but I might end up with code that crumbles to pieces if I try to iterate beyond the MVP.

    Oh, wait! This would be a perfect job for my friend Ferngully (who agreed to let me write about her under the condition that I assign her a silly pseudonym). She recently quit her job to travel but was due back in a few days to look for full-time work. She would probably have time to freelance in the meantime. We had worked together in the past, so I knew she was a solid developer and that we work well together.

    I reached out to her, and she was immediately on board. She knew from our past work that my code reviews are pedantic and whiny rigorous. She told me she was excited about the challenge of meeting my tough standards.

    I wrote a design document that laid out the components of the website at a high level. Ferngully would handle the backend scraping tasks, while I would build a simple web frontend to display the recipes.

    Architecture diagram

    Why aren't we live?

    When I was initially discussing the project with Ferngully, she asked if I had any deadlines. "No deadlines. Just focus on writing good code."

    It's the same thing I tell any developer working on a side project with me. I'd rather receive high-quality code on Thursday than hastily slapped-together code on Monday. I estimated that Ferngully's portion would take 30-50 hours to implement. We'd be done in about a week. Maybe two or three if my estimates were off or if she worked fewer than 40 hours per week.

    At the time, I was in a busy period with my day job. It could be months before I'd have time to build the frontend. Certainly, I'd be the bottleneck.

    After I finished the design document, I thought about how anticlimactic it would be if Ferngully delivered the scraping code only to have it sit in a drawer for months. I spent a few evenings putting together a basic frontend. It displayed some sample recipes I scraped by hand. We'd be ready to add in the full recipe data and launch as soon as Ferngully completed her work.

    Screenshot of website MVP, populated with data scraped by hand

    That's when I started getting anxious.

    It took me a week to complete the web portion, but I still hadn't seen any code from Ferngully. What was she doing?

    Before I built the frontend, the project was stress-free. Now that we had a site ready with dummy data, it felt like we had a living thing that we were keeping caged. With each passing day, my code was withering into obsolescence. I just wanted to show my site to the world so that I could get to the part of this process where Mark Zuckerberg invites me for champagne on his personal-information-collecting superyacht.

    Working under low bandwidth

    Ferngully sent me her first code review at the end of the second week. It was a partial implementation of the first backend component. She had averaged 15 hours per week, but she was starting her full-time job the following Monday. Her hours were sure to go down after that.

    I revisited the design document to see if I could trim anything out. It called for the backend to programmatically upload recipe data to the website's data store. I could reduce Ferngully's work if she just wrote data to a local filesystem instead. Then, I'd use existing command-line tools to upload that data to the website.

    Okay, maybe the limited time was a good thing. If I could trim elements out of the MVP and still achieve the same thing, it wasn't really in its most minimal form.

    I was optimistic that we could wrap this up in a few more weeks.

    Becoming my freelancer's freelancer

    Unfortunately, Ferngully's job reduced her availability even more than I had anticipated. Over the next month, she averaged less than five hours per week on development. At this rate, it would take us months to finish.

    If this was another freelancer, I would have just thanked them for their work and found a new developer. But Ferngully was not only my friend but a friend going through the stress of a new job. I didn't want to add to her plate by pushing for more hours or overhauling the project plan. Nevertheless, I was kicking myself for how lax I had been earlier when she asked about deadlines.

    Maybe I could reassign some of her work to me. No, I'd be annoyed if someone hired me for a job, then did it themselves. I revisited the design document to see if we could simplify it further, but I couldn't find anything to cut out. Then, I began thinking about whether I could adjust our development process to shift some time expenses from her to me.

    Wait a second. What was going on? I outsourced this work to save myself time, but now I was restructuring the project to optimize for Ferngully's time in place of my own. How did I become my freelancer's freelancer?

    Simplifying code reviews

    Regardless of who was freelancing for whom, I wanted us to complete the project, and quickly. The biggest time expense I could cut was my famously picky code reviews.

    The reviews were expensive for both of us. I put a lot of thought into my code reviews, and it took time for Ferngully to implement my suggestions. With days or weeks of latency between review rounds, we were also burning cycles just remembering context for where we were in the review.

    To save time, I decided to stop giving Ferngully notes. When she sent me her next changelist for review, I merged it in, tweaked it a bit to match my standards, and boom -- we had our first complete backend component. Only two left!

    This doesn't make sense

    Ferngully was less enthused about my clever new time-saving technique. The tough reviews gave her technical growth. Without those, this project was just work, and she had enough of that at work.

    I debated whether I could keep doing notes. Even when I was skipping them, I wasn't sure I was actually saving time overall with a freelancer. If I started writing them again, I'd definitely be in the negative timewise. I'd be paying a freelancer a nontrivial hourly rate, and it would cost me more in time than writing the code myself.

    We talked it over and decided it no longer made sense for Ferngully to help build the MVP. With the first component completed, it was a convenient time for her to transition off the project.

    Implementing it myself

    The Saturday night after I wrapped up with Ferngully, I continued where she left off and resolved to keep going until the MVP was live. By 2 AM, the first version was complete. I was embarrassed by how plain it looked, but it was done.

    Screenshot when the MVP was finally complete

    I quickly realized that I should have done the project solo from the start.

    A prototype requires so many small decisions about tradeoffs. Do I spend an extra hour to fix a bug that only affects 10% of recipes? Which modules should have automated tests? It would be impossible to specify these answers ahead of time to a freelancer. Working solo, I can just follow my intuition.

    Building it myself also made it so much easier to fix weaknesses in the design. Even on a team of two, design flaws incur high frictional costs. When Ferngully spotted an issue, she had to confirm it with me, I'd update the design document, she'd read it, throw away some work, then finally reimplement it according to the new design. When I work solo, that whole process is almost instant.

    Finally, by outsourcing the backend, I was obscuring a core part of the business from myself. When I got my hands dirty with web scraping, it sparked ideas for recipe data I could use in future iterations of the site and gave me better insight into the site's design constraints.

    Takeaways

    Despite the issues, this process taught me important lessons about creating new websites and working with freelancers. The biggest lesson was: if you're a developer, build your own MVP.

    If you choose to work with a freelancer:

    • Discuss target completion dates.
      • You don't have to set rigid deadlines, but figure out up front if you're in the same ballpark.
    • Agree on weekly bandwidth.
      • Your freelancer may have other clients or priorities. Find out how much time they'll be able to dedicate to your project.

    This article was originally published on my blog.

    submitted by /u/mtlynch
    [link] [comments]

    Left startup, with payout offer, now former partners want it forgiven.

    Posted: 06 Dec 2017 05:42 AM PST

    Hello,

    I left my start up (Enterprise IT consultancy) after conflicts with the partners. We fought over how much someone should be given for months leading up to end.

    They ended up buying me out at 50k over 2 years. way more than I ever thought we should pay any partner out.

    We are halfway through when they emailed me saying the fired all the employees, liquified all their assets, and are out of money, requesting I forgive the debt. I think they messed up on their largest contract and burned some bridges during that process.

    What would you do? I can sue, a probably fruitless endeavor. I could save the remaining thread of friendship there is.

    I have never sued someone but I can imagine it is painful.

    submitted by /u/papawasagokartracer
    [link] [comments]

    Share term sheets?

    Posted: 06 Dec 2017 01:37 PM PST

    Can we share term sheets (scrubbed of course) with each other? I'm interested in what else is out there. We could set up a repo, or just provide links to individual notes/term sheets.

    Is there anything inherently bad about this? I understand it would be best to understand each document for each scenario (see SAFE documents), but there is surely good reason to share just to look at broad comparisons or industry trends.

    I'm hoping to receive my first note soon so I'm happy to share it (scrubbed of course), once I do receive it. For those who already have a bunch, would you be willing to share?

    Thanks!

    submitted by /u/hayjoss
    [link] [comments]

    Thoughts on starting a company without prior knowledge in entrepreneurship and business, and with possibly no bachelor's degree ?

    Posted: 06 Dec 2017 07:07 AM PST

    I am currently strongly thinking about starting my own company, but the issue is that I, unfortunately, do not have any prior knowledge in neither entrepreneurship nor business at all. On top of that, I might not even get my bachelor's degree.

    I know this all sounds like have nothing to work with, but I am pretty sure my idea could very much revolutionize the current market, and I believe that it will forge its footprint in a matter of months as there aren't any other companies with the same idea as far as I know.

    I am currently in my senior year in an engineering program at Uni, from which I might not even graduate due to some problems with my thesis. However, I do believe that with the skills I acquired so far I might be able to get away with it in an engineering business.

    Any thoughts on that ? Have you been in a similar situation ? Any questions to help you give better answers ?

    Thank you very much in advance,

    A confused undergrad student.

    submitted by /u/Phenome1
    [link] [comments]

    Agile and pivoting

    Posted: 06 Dec 2017 09:48 AM PST

    While I see startup people around me arguing to pivot or not I wonder: where does agile end and pivoting starts?

    How dramatic the change has to be so we can call it pivoting?

    Where is that moment when to consider pivoting instead of doing small incremental changes?

    What were your experiences of having a pivot?

    What problems could you solve with incremental changes instead?

    What were your successes and failures?

    When the decisions to incrementally adjust or to pivot were proven right or wrong?

    Please, share what you think.

    Will appreciate a lot the experiences and practices of yours.

    submitted by /u/dileping
    [link] [comments]

    How does Facebook (or any business) determine what to charge an advertiser to target a particular demographic or combination of demographic's?

    Posted: 06 Dec 2017 09:35 AM PST

    I'm not necessarily looking for hard numbers, just how it's determined that one demographic should be worth more than another. Is the cost simply proportional to a demographic's percentage of the population or the financial status of the demographic or the cost of the product or service being sold or...?

    It all seems very complicated, and I can't imagine that every company that hosts advertising (I.e doesn't use a third party) is just figuring all this stuff out from scratch. Is there a go-to guide for this or industry standards or a rule of thumb or something else?

    submitted by /u/967421
    [link] [comments]

    No comments:

    Post a Comment