Adforprize

There are multiple paths to constructing a piece of software from start to finish.

An individual programmer can build an entire product from scratch in a couple days. A giant corporation can commission a project and delegate responsibilities to hundreds of people. An open source community can use the wisdom of the crowds to efficiently build an operating system.

Today’s episode is about another path for building software, and my own experience traveling that path. I designed and contracted an app called Adforprize that is now available on the iOS app store.

Designing an app and contracting it out to an engineer to build is a worthwhile exercise for most people in the tech industry–whether you are an engineer or not.

This post has two main arguments:

1. the process of designing and prototyping an app is useful and educational for anyone
2. it is now cheap and effective to hire a contractor to build a working version of your prototype

As with the previous monologue episodes such as 10 Philosophies for Engineers and You Are Not a Commodity, there are no advertisements on this episode. Please email me any feedback you have–jeff@softwareengineeringdaily.com

Why This Matters To You

Everyone has an app idea, and many of them are pretty good.

You have probably had a conversation with a friend where one of you says “hey, wouldn’t it be great if there was a 2-sided marketplace for bacon?” Or “hey, wouldn’t it be great if there was an app where users could take a selfie and instantly see what celebrity they resemble the most?”

These things would be cool! But most ideas end with the ideation.

Who has the time to implement these things? Most of us are busy at
work, where we spend our time and mental energy dealing with the technical complexity of our jobs.

If you are a “smart creative”, when you get home from your job, you probably don’t want to spend your leisure hours reading iOS documentation and slowly learning to write the necessary code for your bacon marketplace app.

Smart creatives who have a busy full-time job often have a hobby with more immediate gratification, like playing an instrument or blogging. Some of us also write apps on the side, but if you don’t already have all the requisite skills for writing an app, the prospect of reading tutorials and documentation can make the feeling of ever publishing an app seem so distant.

There are many people listening to this who are
better at sales, marketing, design, or product management than they are at programming–they want to build an app. One common narrative is that if these people want to see something built, they need to learn to program, and that’s not true.

There is a more fun, fulfilling way to build an app than learning to code in Swift or React Native–contracting out the programming to someone else.

Designing an app is a fun exercise. Building a prototype with tools like Sketch, InVision, and Keynote is free and frictionless. Most people listening to this probably spent some time drawing in KidPix or Microsoft Paint or PhotoShop when they were a kid.

Most of us know how to draw at some basic level, because we spend all

day seeing and understanding images–drawing is second nature to anyone who can understand shapes. Similarly, we all know how to design apps because we spend all day using them. We understand the purpose of a button or a slider or a swipe.

But most of us have no idea how to configure the code around this user experience–the buttons and sliders and TextViews.

Along with the design process,   the business ideation process is also fun. It’s fun to imagine business models and viral loops and ways to drive user engagement. But without the capability to build the app that embodies your business ideas, it is less fun to think about those ideas. And again–most of us don’t relish the idea of struggling through the compiler errors and Stack Overflow posts that an app implementation requires.

We’ve all become product designers. We are using our phones all day–most of us have naturally developed a good intuition for how an app should function.

Product design ability is naturally acquired by being steeped in technology all day. If you are an employee in marketing, sales, or design (and certainly engineering) at a tech company, you will naturally learn how to think about product.

Importantly: you probably even have a few good product ideas yourself!

This article is about why and how to prototype your own ideas and communicate your intent as a product designer–which is an incredibly fun process.

If you can afford it, you can then hand off your prototype to a contractor for engineering implementation.

Working at a tech company, you might have accumulated some excess cash. You can invest that $5,000 that you have sitting around by contracting a product in your spare time. This can be a much better investment than something like stocks or ETFs, and it is more satisfying and durable than taking an expensive vacation.

The experience of contracting a product teaches you skills that might not be stressed in your 9-5 job: management, product design, user experience, budgeting, communications, and engineering limitations.

Why Now?

The first version of Uber was written by a contractor. The Uber founders clearly communicated the specification for their product to the contractor, and they got what they asked for.

Contracting Uber was easy for the founders. They had millions of dollars from their earlier startups, they had a network of contractors to choose from, and they had experience hiring people.

There is now a set of technologies that are enabling this for the average person.

• Reputation marketplaces: Upwork, Fiverr, and other talent marketplaces have a rating system that holds workers accountable in the same way as Uber and Airbnb. Contractors who have maintained a high reputation through hundreds of hours will do your job well. These marketplaces also provide massive accountability and price transparency. A contractor who screws over naive customers cannot sustain a high rating. Some people have had bad experiences with Upwork and Fiverr, but that happens with all marketplaces.
• Better communication tools and behaviors: InVision lets you easily convey your product idea. Slack, Trello, Campfire, etc make it easy to communicate with your contractor on a regular basis.
• Minimal-effort scalability infrastructure: Heroku, Amazon S3, and other autoscaling products remove complexities. This makes it much more straightforward to architect a typical application for a single contractor.
• App mechanics: Our expectations and intuitions for how certain types of apps should work are becoming refined. From a recent NY Times Popcast discussion: “Musical.ly is a social app. It feels a little bit like Vine. A lot of familiar mechanics. You like things, you follow people, it has a timeline.”

The last point deserves further emphasis. Cool new apps are often interesting remixes of well-defined mechanics.

Mechanics such as newsfeeds, likes, photo sharing, map-based ride-sharing overlays, swiping interfaces, and social media integration are a palette of interesting ingredients that have lots of new-product mileage left.

These types of features are so widely used that their implementation is well-understood and documented. You don’t need to find an expensive contractor who specializes in swiping or newsfeed architecture–you will be paying a reasonable market rate.

“Wantrepreneurs”

Programming ability is not a prerequisite for being a good product designer and operator.

And yet–the negative term “wantrepreneur” is used to describe someone who has ideas but has not built/shipped anything substantive. If you listen to Silicon Valley type of podcasts, you will occasionally hear a venture capitalist or angel investor use the word.

It’s offensive and shame-inducing and should be removed from our lexicon.

But–it does accurately describe many people in the tech industry (albeit in a condescending and discouraging manner). Oftentimes, this same type of person wants to know what to do if they cannot find a “technical co-founder” (someone to build and iterate on a product).

Contemporary product development literature mostly advises against contracting, but it can be a good strategy if you have a product idea you really want to get out the door into the hands of users.

The conventional reasoning against hiring a contractor to build your product (and why it is mistaken):

1. A contractor has no vested interest and might do sloppy work (the vested interest is the rating system that allows them to keep working on their platform like Upwork–where they will have 100+ hours of prior work if you are discerning employer)
2. If you decide to iterate, the contractor can raise the price for subsequent iterations (again, a contractor on a reputation platform is unlikely to do this and if they do you can find someone else; switching cost is not that high)
3. If the contractor does sloppy work, you won’t know if it’s sloppy because you are not technical (you can ask a friend who is a developer to look over the finished code base; if your friend says it is sloppy then you can find a new contractor for future iterations)
4. Even if the MVP works, it will fall over if you hit any amount of scale (unlikely to happen if you deploy to Heroku/AWS)

In today’s tech scene, there are tons of people without the ability to code who nonetheless have excellent product design abilities.

Whether you are in sales, marketing, or customer service, if you want to build a product someday, or even if you just want to move from your current role to a role in product management or design–consider designing and prototyping an app, and having a contractor build it.

If you have specific ideas for what you want built, and you have some extra cash lying around, contracting an experimental app is awesome.

Engineers Too

There are plenty of programmers whose job roles do not require them to think about product design.

I spent three years engineering backend Java systems, and there was rarely an interesting decision to be made about the end user’s experience with the product itself. It was all about implementation.

You can spend a whole career like this, never grappling with problems higher up the stack. If you are planning to do that, then you will make a lot of money–why not spend $5k of it delegating an app to a contractor?

You might find out that you love product design and development even more than backend engineering.

I’ve been thinking about contracting an app ever since I heard the story of Uber’s prototype. More recently, when Seth Godin came on this podcast, I asked him about the engineering challenges of building Squidoo, the second company he sold. As it turns out, the minimum viable product for Squidoo was also written by a contractor.

My biggest takeaways from that brief discussion with Seth: have your deliverables as well-defined as possible and you won’t have to iterate in order to get the product out the door as you imagined it in your head.

The Uber and Squidoo examples are interesting because Kalanick and Godin both studied computer science, but they still opted not to write their apps. They decided the work would be done faster and more effectively if they delegated.

As an engineer, I have been building janky minimum viable products for the last five years because I assumed that was the way it had to be done. Each time I designed and built an app, the end result was unimpressive. Because I wasn’t focused entirely on the product design OR the engineering, I did a poor job trying to do both.

This is one of the most common fallacies that keeps programmers in a position where they have to take orders.

The programmer is conditioned to believe that delegating something means admitting that you are incapable of doing it. Programmers are taught that it is more valiant to spend hours reading documentation and doing something on your own than to delegate your work to someone who won’t have to read as much documentation, and will do it faster and more cleanly.

After hearing about several stories of contracted products that turned into successful companies, I decided to experiment with the contracting process myself. I would focus on product design and hire a contractor to write the software.

Ideation and Prototyping

When we think of product designers, we often think of a bolt of inspiration coming to an inscrutable genius like Jack Dorsey or Steve Jobs or Elon Musk.

The reality is that effective product design can be learned by anyone who is willing to put in the hours, study the craft, and iterate. From Airbnb to Facebook to the wide range of products on IndieHackers.com–successful products come from people are constantly experimenting and toying around with new ideas.

A product designer lives and breathes research and development. The effective product designer is constantly studying the world and running experiments in her own life. She crafts her environment to be conducive to new ideas, and keeps her calendar peppered with blank space where she can reflect and let new ideas come to the surface of her consciousness.

I keep whiteboards around my apartment to write down product ideas and other fleeting moments of inspiration.

Back in college, I was on a diet of homemade Soylent and I was having awful fever dreams due to related indigestion. I had misread the recipe for Soylent that I found online, and had accidentally put three times the amount of fiber in my mixture as the recipe called for.

I woke up at 2 AM from these Soylent induced fever dreams. I have heard that people often think up their best ideas when they wake up at 2 AM, because the boundary between your consciousness and your unconsciousness retreats a little bit.

In this case, I was struck by an idea for a user-generated advertising platform, where companies would offer contests where people could compete to make the best ads. I sketched it on one of my whiteboards and went back to sleep for a few fitful hours.

When I woke up, I copied the idea from my whiteboard to a spiral notebook, and then forgot about it.

Years later, I was working at an advertising technology company, and I started to see some of the inefficiencies in the advertising industry. I realized that my idea from back in college might actually have merit. I started building a prototype called Banner Warhol, and I completed it in a few weeks.

Along the way, I seeded it with some fake ads I made (thanks to Michael Rosenthal and Josh Stewart for helping with the design).

This was a decent idea, but fraught with mistaken execution:

• There was no concrete hypothesis; once I launched, how would I define success and failure?
• There was no target user base–how would I get distribution?
• Who cares about banner ads?

I didn’t know what I was building or why. I had a vague sense that user-generated advertising could be cool, and I started hacking on the idea without thinking further.

I have no professional experience writing front-end apps, and it shows with Banner Warhol. Consequently, the code base quickly became a disaster. I got sick of the project, and I quit: the classic abandoned side project.

As I said above, in this case the engineering was a distraction from thinking about the product. I was afraid to think too deeply about the product I wanted to build because I was afraid I wouldn’t be able to engineer it.

If you are trying to play both product designer and engineer, there can be inherent cognitive dissonance.

I abandoned the idea for a year and a half, going to work at Amazon and then focusing on building this podcast.

But–the idea of user-generated advertising has stuck with me, and when I read futurist Kevin Kelly talking about it in his recent book The Inevitable I knew there was something yet unexplored:

“With a peer-to-peer system, these ads would be created by passionate (and greedy) users and unleashed virally into the blog wilds, where the best ads would evolve by testing and redesign until they were effective.”

If you replace the word “blog”, with “social networking”, the idea for peer-to-peer advertising becomes quite compelling. Social networks are where advertising is most effective today–so the question became, how can you build user-generated advertising into the social network ecosystem?

Snapchat has added features around user-generated advertising and Instagram models make deals with advertisers. These ideas scratch the surface–but user-generated advertising is not just a feature, or an idea that you patent. It is an entire medium of expression.

We need an entire platform for making ads.

People should be able to make advertisements for products, ideas, and movements. They should be able to see each other’s advertisements, to Like and Comment on them, and connect with brands who want to use those advertisements. This would lower the cost to the brands who currently work with overpriced agencies to make their ad campaigns.

Armed with this hypothesis, I thought about the minimal way to run an experiment.

Who is a user base that is most likely to latch on to a product that lets you make ads?

I was thinking about this question when I was scrolling through Instagram and saw a cache of people who are making their own ads already–Instagram fitness instructors and models.

Many of these people are trying to build a personal brand, and in doing so they advertise for products like protein shakes, meal plans, and fitness programs. They may have 2000-5000 followers, which is respectable but not highly monetizable. Most big brands will not do business with this type of person.

Nonetheless, they are “influencer marketers”. This mid-level amount of “influence” is going largely uncaptured. It is like blogging before Google AdSense.

From Instagram to Vine to YouTube to Facebook, there exists the challenge of connecting influencers to brands they should be representing, but on Instagram this problem seemed most acute.

My idea for a workflow was:

1. User takes a picture or video
2. User attaches a brand to the media, turning it into an advertisement
3. User posts the advertisement to Instagram

It would have the familiar mechanics of a photo sharing app so that people felt like they were using something they had used before.

I took out a notebook and started drawing diagrammatic ideas. When I had the idea fleshed out on paper, I moved to Sketch, a Mac OS tool that is like Photoshop. Stitching together pictures from Google Images, I made the design as crisp as I could.

I had no prior experience with Sketch. It is an awesome piece of software and is more intuitive than I expected.

After creating screenshots for the workflows I wanted, I put together an Invision to further describe the functionality of the app. Invision is a fantastic product for communicating UX and design.

I like Invision because it is easy to share your prototype. At Apple, product designers use Keynote to create prototypes that feel like apps, so that is a viable choice as well.

When I finished the prototype, I wanted to get it into the hands of users. But, I was working on Software Engineering Daily full-time. I already had a lot on myplate, so it was important that I used my spare time efficiently.

For a few weeks, I tried to learn modern iPhone programming. My pace of learning was so slow and I was not motivated by learning the syntax and the design patterns of mobile development. Thinking back to how Uber and Squidoo were made, I decided to contract my advertising platform–which I was then calling “Adstagram”.

Contracting

I logged onto Upwork and searched for iOS developers with experience on photo sharing apps, quickly finding someone who was top rated and worked for $66/hour. I asked him for a demonstration of his work and he showed me a photo sharing app he had built in the past, which he could reuse some of his code from.

I sent him the prototype and asked him for a quote as well as a description for how he would build the app. His price was reasonable and the architecture he proposed was simple, so we got started with a first, simple set of milestones to hit.

As a software engineer, it was easier for me to evaluate that his estimations of time and cost were reasonable. If you are not an engineer, you can check with an engineer friend to see if what a contractor is offering you is fair.

Upwork creates an escrow transaction for each set of milestones you define. I defined milestones in terms of high-level functionality and capabilities that were a subcomponent of that functionality.

For example, the following list of user story functionality requirements could make up a milestone:

1. Taking and editing a picture/video, or uploading from library
   1. I can take a photo or select one from my library
   2. I can shoot a video using different segments, like Vine/Instagram
   3. I can use brand search with autocomplete to select a brand for my picture/video and it will add a logo
   4. I can move the logo to different locations in the picture
2. Sharing the photo
   1. I can share a photo in my Adstagram feed
   2. I can share the photo to Instagram
   3. I can share the photo to Facebook and Twitter

Each milestone was a small amount of money, and gave me a feel for the pace at which the contractor worked, and helped me predict what the final budget might be. After each milestone, he sent me a working version of the application thus far.

I was testing the app after each milestone, and this put me in the shoes of the user. During testing I identified an issue with an image search feature within the app. I made a flow chart in Gliffy to be clear about how I thought it should work.

Four months after initially contracting the app, the functionality is complete and the price tag is under budget–it took $3100 to build, and I gave the contractor a $400 bonus for doing a great job and being responsive.

You can now download Adforprize in the iOS app store. I use the app on a regular basis, and I’m looking forward to seeing how people respond to it.

If you have an iPhone, I would love if you checked it out, and if you like it then rate the app on the app store. I didn’t ask for ratings on the iTunes store very often for this podcast–because I’m not convinced ratings matter that much for podcasts. But they definitely matter for apps.

Epilogue

For many people, the most coveted job in tech right now is “product”, whether that means product design, product engineering, or both.

We dream about drawing something on a whiteboard in a conference room during a meeting, and then seeing a finished product come across our desk a week later, so we can evaluate it, critique it, and send it back for another iteration.

How do those whiteboarding product phenoms get such an awesome job? By practicing and getting good. Why else would anyone talented follow their lead? One way or another, these “product” people have accrued experience and are rewarded with responsibility.

Adforprize has gone from being Soylent-induced nightmare idea to a reality that you can download from the app store. Now begins the long, cyclical slog of getting people to try it out, realizing that numerous UX issues make it confusing and terrible, and paying a contractor for continued alterations.

My hope is that the app gets some traction, and it will make sense to hire someone full time to work on it. If Adforprize falls completely flat, and nobody cares about it–that’s OK too. I have had a ton of fun building it, and the education was worth twice the price. I’m happy to pay the cost of tuition.

Jeff