Building a Better Web Application: Part 1

There are millions upon millions of developers around the world – many are insatiable technical problem solvers. As smart as they are technically, many lack the business aptitude to build a Web application that gets the attention they hope for. This series of posts is intended to help anyone else who is struggling to get from their rough idea chiseled into a popular landmark on the web for a niche audience. In this series, I’m goin to use the premise of creating a fictitious application and walk through the basic steps for anyone willing to listen. To appropriate set expections, you should know that I’m not going to actually build the application in my premise. I’m simply using it as an example because many of us learn by seeing the model first.

Let’s begin!

Developing a Mission Solving a Problem

We’ve all heard about mission statements for sites. Most mission-building is completely and hopelessly bogus! You’re wasting your time, the time of those who will visit your application, and the time of any VC’s you plan to pitch to if you spent hours creating your mission. Stop taking advice from MBAs. Entrepreneur, Garry Tan, defined building a successful business as a three-step process during his Seattle 2.0 Startup Day keynote:

1. Hate The Problem
2. Ship the Product
3. Love the Customer


I repeat those words every morning that I wake up – seriously. There’s no “mission statement” in there. Your mission statement, if you must have one, should be to solve the damn problem! If you are going to spend a large amount of time developing anything (other than the code for your application), spend it on refining and solidifying the problem statement. What exact problem is your app going to solve? If you aren’t solving a problem, my guess is that your app won’t be popular.  Furthermore, if the problem doesn’t wake you up in the middle of the night or otherwise drive you insane thinking about it, then you may not be the person to solve the problem.

When solving any challenge, empathy is king. The ability to feel the pain of others with the same problem will be the driver of passion that helps you beat your competition.

Not all problems are considered important by all people. For instance Facebook solved a social problem. They didn’t solve world hunger. They allowed awkward people to stalk the pretty girls on campus from afar without getting maced. I suppose they solved a few other problems too, but let’s face it – social web apps are popular because we all just want to stick our nose in other people’s business. For Mr Zuckerberg, that was a problem worth solving. With Facebook’s success, who could argue otherwise?

After saying all of this and you may be thinking “If it’s not important to have a mission, why are you talking so much about it?” If you’ve said that, you may as well put this blog away and go back to what you were doing before because you aren’t paying attention. First of all, talking about what you shouldn’t do is important. There are so many MBA programs and certification courses that explain the process of “defining a mission”, [sarcasm]you’d think there were companies who made a living just creating them[/sarcasm]. (In case you didn’t pick up on the sarcasm, there are indeed MANY businesses doing just that.) Second, I didn’t say you don’t want a mission. I just said you don’t want to waste too many cycles thinking about a mission statement rather than investing them on the problem.

So let’s move onto the problem, shall we?

Step 1: What’s Your Problem, Buddy?

Don’t go crazy trying to think up buzz words and find the perfect marketing phrase here. You only really need those eye-catching phrases if you are going to pitch your project to someone else (a VC, another developer who you want to help you, or any other person you want to approve of your project for some reason). Just write your problem statement in plain and simple terms, and then move on.

For the purposes of this blog, we are going to focus on a common problem: “Getting content relevant  to my exact needs through all the piles of useless stuff out there is a pain in the ass!”

“Tobin, that problem is dumb. Everyone and their uncle has solved this problem already!” you may say? Well, let me ask you these questions: Do you have all the content you want? Is it organized how you like? Is it delivered the way you want it delivered and when you want it delivered? This is what I mean by refining the problem. If other’s have “solved” the problem, but you are still not satisfied, then they really haven’t solved the problem yet, have they?

Stepping back and thinking broadly, in this process, you’ll want to define what exactly is bugging you. There is a TON of content available. There are also a TON of sites aggregating or curating content in multiple forms. You’ve got Guy Kawasaki’s AllTop. You’ve got Hacker News. You’ve got Reddit. There are a million sites/web apps out there that will either automatically aggregate your content, allow the community to democratize what you will read, provide you with the tools to point at your own resources or otherwise dictate what’s important and cram it down your throat. Still, you have to think, are these sites getting me exactly what I want or need to know about? How much content do you filter through before finding a priceless nugget? Is the signal to noise ratio high or low with other solutions you’ve found? Think about this problem until you strike a nerve that says, “Damn it! That problem needs fixed and I know exactly what to do to solve it!”

Are we done yet? Not even close.

Sometimes we have more individualized problems. We, as humans, have this ability to pick up a turd, polish it and kiss the hell out of it as though it was your long-lost partner.  If you put your particular “piece of shit” up to the lips of several other people and they kiss it too, then THAT is no piece of shit at all — it’s gold! Do some searching on industry forums. See if others are complaining about the same problem. Set up some searches on twitter for people talking about the problem. Ask around the community what other pain points people are having and see if your problem even ranks up there. Some problems only affect a small number of people. Sure, you can build that solution, but don’t expect to get rich off of it unless you can sell it at a very high price tag.

Once you have your problem defined, refined and verified by others, write it down and move to the next step. For our example, I’m going to define my problem as:

The content that is most relevant to a developer’s evolving needs is buried in a pile of useless material and is never discoverable when they need it.


Step 2: A Purpose-driven Application

OK, you defined your problem and one would think that your purpose is to “solve the problem” as I stated earlier. That’s true, but you still want to define a basic purpose for your web app that explains what you are going to do with that problem. The scope of the problem might be too big to solve it all. You might want to tackle a specific aspect of that problem. You may decide to take a very limited view of the problem and let your application tackle that while ignoring the rest or saving it for later. Let’s go back to the example problem I set above and define the purpose for our site.

The purpose of <x> is to curate the best developer content targeted at an individuals needs and deliver it to a customer how they want and when they want it.

There’s actually a whole lot going on here and I hope you picked up on it.

First, notice that I haven’t given my solution a name yet. That’s really the last thing you should be thinking of now. I just put a nice <x> placeholder in there for now. You can figure out a name that fits your solution once you’re further along in the process.

Second, notice that I emphasis “individuals needs” in the purpose. The purpose I’m defining is to have customized curation and that will require that I cater to individual needs.. There is nothing about customization in the problem statement. But I’m defining how the purpose of my application is going to approach the problem.

You may ask, “But what if I change your mind later?” That’s actually fine. Most companies do evolve and change their approach over time. Amazon stopped being “just a bookseller” and has become a massive retail affiliate as well as a content publisher/distributor. Facebook started off with the “exclusivity” that targeted individuals at Ivy League schools. One would have a hard time arguing that 400 million profiles still provides any exclusivity. You’ll change your site’s purpose, and even the problem you solve may, and likely should, evolve over time. So don’t feel “locked in”. Solve your problem (defined in step 1) now, and iterate as Garry’s 3-step plan intimates.

Step 3: Who’s Hero Will You Be?

You’ve defined your problem, and the purpose your application will play in solving that problem. It’s time to refine who’s hero you’ll be. That’s right. If your problem really is a problem, someone is going to look at your application and say “HELL YES!” and want to kiss you or do other inappropriate things. OK, you won’t be a rock star or anything, but you’ll definitely catch their attention.

Be a hero. However, define specifically who will be the lucky recipient of your benevolence. You can only help so many and you want to treat them like GOLD. So keep refining until you have an audience small enough for you to be attentive to.

In our example so far, we have mentioned that we will be targeting software developers. That’s the extent of our refinement so far. This is a VERY large group and you’ll want to start off targeting a smaller group. “But, I want a large audience so that I can maximize profits!” is a common response. Your not going to be able to serve that large audience. You can’t LOVE THE CUSTOMER if your customer pool is so broad that you can’t empathize with each of them. Trust me, if your application solves a significant problem for a niche of an audience, you’ll grow your application to serve more people over time and hopefully you’ll hire people who can empathize with the larger target market. When we defined our purpose, we defined the approach that we would take to solve a problem. A professional developer and a beginner developer are likely going to need different approaches in order for your application to be their ideal solution. So in this step, we are going to refine this audience to the group that you can empathize with most. In my example, I’m going to add the following refinements to the developer audience:

  • Professional and experienced
  • Standards-compliant web developers
  • Passionate about the field

For my example, I’m stating that I am going to target developers who are professionals. They have been in the business a while, know the terminology, understand the landscape of development, and really just want to find content that keeps them up to date. This reduces the need for me to spin cycles explaining basic concepts like dependency injection, SOLID, DRY, etc.

I’m also going to target standards-compliant web developers here. I’m not going to concern myself with telling people how to write code that works on proprietary systems. To support a customer trying to do proprietary things means I have to learn about their system first. I don’t have the bandwidth for that, so let’s focus on the standards that we all know and love.

I’m not going to try and convince people to be passionate about development. My audience should already have a passion for development. This reduces the need for me spin cycles “selling” the content. It should sell itself.

Notice how each of my refinements were focused on excluding people from the larger pool I originally selected? These refinements were also meant to reduce the amount of time I’d need to spend catering to the audience. You should add those refinements until you feel you can speak to the hearts of those you intend to serve.

Step 4: The Broad Strokes

So we’ve defined a problem, explained the purpose our app has in approaching the problem, and have defined who’s hero we’ll be. Sounds great. Now we need to understand the broad strokes of functionality we will provide within our apps purpose for living. We aren’t diving deep into features yet. That’s a bit premature. We are talking about the broad feature set rather than the implementation details at this point. For instance, if I were designing the first car ever made, I might pick the broad features like “go”, “stop”, and “turn”.  Much later in the process, I would likely define that I should be able to “go” both forward and reverse or maybe even sideways. I would also later define mechanisms like a gas pedal, break pedal and steering wheel. For now, we’ll just stay with the broad strokes. You might write them down like this.

  • Low-Barrier Community Contribution
    • Let’s not worry about what all they can contribute yet
  • Rewarding Community Interaction
    • Interaction Let’s not worry about what kind of interaction yet
  • Compulsive Browsability
    • Let’s not worry about what pivots we can browse or otherwise filter content on just yet

    Now think it through. Do these broad strokes solve the problem you defined?

The content that is most relevant to a developer’s evolving needs is buried in a pile of useless material and is never discoverable when they need it.

Well our first bullet, “community contribution”, allows for developers to vet content that is submitted by others. The community interaction could allow for the developers to further refine what content is good and what is bad. Compulsive browsability means that the content is so easily discoverable that you can’t stop browsing – like when you get stuck on YouTube or LiveLeaks watching videos all day. That ultimately takes me out from under the “pile” of useless material.

So now that you’ve written down your basic functionality, and aligned it to your problem, you’ve discovered that you don’t completely solve your problem yet. This is a good thing. You’ll want to add or remove some broad strokes until you feel that your problem is solved.  I’m going to add the following additional functionality:

  • Personalization
    • To fit the evolving needs of an individual, you’ll need to have some sort of personalization. Let’s not worry about what personalization yet.

    Next look at the your purpose:

The purpose of <x> is to curate the best developer content targeted at an individuals needs and deliver it to a customer how they want and when they want it.

Does your application meet it’s purpose? We are going to curate the best developer content and target it at individuals needs. But we haven’t talked about delivery yet. Are we just going to deliver through a web page?

IMPORTANT NOTE: According to an article on tech crunch, time spent on Mobile Apps has surpassed time spent web browsing.

You would be wise to consider the fact that you need a mobile component. Also, there are thousands of feed readers and aggregators already working for developers on some level out there. Wouldn’t it be wise to provide data in RSS? Let’s not dig into the specifics of the implementations we’ll provide delivery through just yet, but we need to define the broad stroke of this functionality so it isn’t missed.

  • Diverse Delivery
    • Again, let’s not define all the implementation details of delivery just yet.


We’ve actually done a lot in very little time. We’ve defined a problem that get’s us up in the morning and the middle of the night. We’ve defined the purpose our application will play in solving the problem. Furthermore, we’ve defined who the people are who will find our approach most rewarding.
We have now defined the foundational broad strokes our application needs to provide. We’ve further expanded on those broad strokes in order to solve our problem with our application’s purpose in mind and with our audience in mind too. As a result we have five broad swaths of functionality we need to provide.

Note: This is part 1 of a series of posts on building better web applications. If you wish to continue, please read part 2:

Feedback is appreciated. I intend to revise this post and keep it updated based on community feedback. Thanks for reading.

Be Sociable, Share!

    16 Thoughts on “Building a Better Web Application: Part 1

    1. Pingback: Tobin Titus » Building a Better Web Application: Part 3

    2. great fucking post 🙂

      oh & thanks for the attribution, however i’m pretty sure i stole that triplet from Garry Tan (who was also speaking at Seattle that day). wish it were mine, but regardless i love that saying:
      1. Hate The Problem
      2. Ship the Product
      3. Love the Customer

      (garry, i hate that u came up with that & not me, goddammit! awesomely pithy ++ , FTW!)

      regardless Tobin, loved your take on this stuff… nice writeup.


    3. Thanks Dave. Sincerely means a lot to get your feedback — even more that it was positive feedback. Attribution has been corrected to point to Garry. Sorry to Garry for getting that one wrong. It was great regardless of who said it. Glad I got to talk to Garry briefly at Seattle 2.0 Startup Days too. Y’all both rock.

    4. Super post! I have been sitting on the fence about something I wanted to build, now you have given me the right filters to actually vet the idea and take it a few steps forward!
      Looking forward to the next part…

    5. Pingback: Tobin Titus » Building a Better Web Application: Part 2

    6. Good post, Tobin!

    7. @Sumit Glad to hear it! It’s always nice to know that your blog post has inspired someone to action. The next part has been posted. Check back for the continual updates. I may post part 3 in the coming week if I have the time.

      @Peter I sincerely appreciate the feedback Peter. I highly value your opinion and appreciate that you took the time to respond.

    8. Excellent post. I enjoyed reading it.

    9. Double D on July 7, 2011 at 5:17 am said:

      Great Post!!! Look forward to reading more!! Like other have said, have a couple ideas that have been rolling around in my head for a couple years, just what I need to help get focused and started.

    10. fallahwithanidea on July 28, 2011 at 8:20 am said:

      Bravo! Good post.

    11. @fallahwithanidea
      Thanks much for your feedback and for taking the time to read the post! 🙂

    12. Super post, it is great to see app development broken down in a clean and clear way. Thanks for taking the time to share.

    13. Nicholas Stein on August 9, 2011 at 5:48 pm said:

      I have been stewing about an application for couple of months and I am using this article to get me through the project definition phase. I particularlly appreciate the narrowing of audience part of the post. How can you love the customer if it is everyone. Find the dozen “stout hearted men” and they will spread the word.

      • Thanks Nicholas. I appreciate the feedback. If you run into any snags using this method, please let me know so I can determine if I should modify the post accordingly.

    14. Pingback: Building a Better Web Application: Part 2 | Tobin Titus

    Leave a Reply

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

    Post Navigation