All Posts in Uncategorized

November 26, 2014 - No Comments!

What Podcasts are you listening to?

My Favorite Podcasts

Lately podcasts seems to be getting some attention, so I thought I would share my favorite Podcasts.

  • Dan Carlin’s Hardcore History. This one is my favorite. I wasn’t interested in history before, but after listening to Wrath of the Khans series, I became addicted, and I’ve been listening to previous episodes since. The best thing about it is that Dan Carlin tries to draw a scene of which you get immersed into.
  • SERIAL. Most popular podcast on iTunes. It takes you through the journey of investigating a true story murder-case by talking to people involved and reviewing the evidence. It will leave you wondering each episode over who did it.
  • StartUp Podcast. Same theme as SERIAL, but instead of investigating a murder-case, it’s about documenting the process of starting a business without knowing anything about starting one. It shows the struggle and inner conflicts that startups go through.
  • The Vergecast. Wraps-up the The Verge’s weekly topics. It’s fun to listen to, and saves me from reading a lot of articles online.
  • DRT or Dorm Room Tycoon. This is the oldest podcast I’ve been listening to. It has awesome interviews with different people in the tech industry about business, design and technology in general.

What’s yours?

March 20, 2013 - No Comments!

The Native Setup

I’m just a designer, but some stuff happened that resulted in me developing a whole REST API in Ruby on Rails. It was the first time for me to use Ruby but thanks to Rails community and Gems I learned fast and did something decent in no time.

Anyway I just want to share technologies we are currently using.

Server Setup

  • Ubuntu 12.04
  • Latest Nginx from Ubuntu
  • rbenv: To manage rubies for projects
  • Ruby 1.9.3
  • Rails 3.2.11
  • Redis: Used by Resque for background jobs

Rails Gems

  • Mongoid for mongodb
  • Devise for authentication and oAuth
  • RABL for formatting JSON responses
  • HTTParty for sending push notifications to pushbots
  • SendGrid for sending emails
  • Paperclip + for uploading attachments and sending them to Amazon S3
  • NewRelic for application monitoring
  • Mina for deployment, a lot smoother that Capistrano
  • Foreman for process management
  • Unicorn for running application server.
  • Resque for background jobs

Local Tips

  • Anvil. A utility for mac that allows you to drag any rails application and it will keep running and can be accessed via
  • Genghis. An awesome tool for connecting to MongoDB. You can even set it up on the server to be accessed from any web browser.

March 17, 2013 - No Comments!

Mistakes of a Native

No matter what you read in books or others tell you, you will make mistakes in your startup, so accept it, learn from it and move on.

1. A Team of Founders

Never hire when you start. It should be always team of founders, 2-5 having 3 the perfect number for Design, Development, and Business. Hiring people to do your job is not the solution, because no matter what you do, they will still be employees, in their thinking and in their way of working. Going for a one man show is possible but don’t expect to release anytime soon.

2. Hire the Heart not the Brain

When hiring don’t choose the best developer for a group of interviewee’s hire the one who got the heart and passion for what they do, hire people who follow their heart, hire people who match your Startup culture and mindset. They are the people who will stay up all night for the release day, they are the people who are willing to give what it takes, they are the people who will not ask for tasks if they are free because they know what needs to be done.

3. Defined Hierarchy

Startups tend to be loose and friendly —which is cool. But without defining responsibilities and decision makers discussions will have no end. So be sure that you listen to others, explain your point, then take the decision or let the responsible one do it.

4. A Moving Platform

This one is critical, for a social network, never start with closed platform. I can’t stress this hard enough. When you target wide and broad set of people a closed platform will always require a set of other platforms. Here is a scenario “We are on iPhone”, “Do you have Android?”, “No”, “Windows”, “No”, “BB”, “No”, “Can you make one?”.

That is really annoying but its the truth, everyone will always want his platform, and hiring teams or freelancing to develop on all these platform and maintaining them requires a hell of a budget. So IMHO go for a JS web application with local storage from the start, unless you are relying on Apple or Google mobile API to do something cool or replying on the AppStore to advertise your application. You can always target specific mobile platform later.

5. Find your customer

Don’t look for the customer after you release or while testing, go look for the customer before you even start. He is the one who is going to pay, do don’t imagine the situation for him, go in forms, twitter, facebook and find out what annoys the user and what other competitors are doing wrong, then go do it better.

You can tailor a software for yourself, but you still need to find other customers like you with the same problems.

6. Never code without testing

Coding without testing is like climbing without a safe rope. Don’t expect your code to be working the same way after refactoring or adding a new feature. And relying on the tester to test all the cases he tested before is just bullshit. I’m not saying there should be no testers, but when discovering a flaw, it should not be able to make its way back to the application, and saying that its a waste of time or it will take more time, is more bullshit, because fixing bugs and re-fixing them will take more time from what you are trying to save.

7. Don’t sprint in an endurance race

The no sleep, no life, motivation speeches thing doesn’t work. In order to have a clear mind that is ready for work you need to stop the sprinting mentality with an endurance one. Go workout, have a good sleep, eat healthy, play from time to time, go watch a movie or a show, it’s not a wasted time, it’s what your mind needs in order to keep moving, and it will keep you from getting depressed. So keep your “all out” energy for times that you really need it.

8. Quality, Time, and Features

There is always sacrifice, and the best way to do it is to choose what are you willing to sacrifice. You can choose product quality with known cycles, but rolling features will be slow. You can choose definitive cycles and with lots of features, but quality will suffer. And finally you can choose quality and features, but take as long as you need or set a 3 months to 1 year period to make something perfect and polished.

It doesn’t matter what you choose as long as you know what you will sacrifice, and make peace with it.

9. Make some $$$

Don’t wait for enforcements to come, your alone in this shit hole, no one cares about your nor your startup, even if everyone likes the idea, doesn’t mean they are willing to share the risk with you. So the only way to deal with this is acting like there is no fund is coming, and find a way to make money before making your application. Show your worth before asking for money.

10. Launch

Launching is one of the hardes moments in your startup. It’s just a mixed feelings between fear and joy. You want to launch but scared that something will go wrong. So no matter what, launch first with little features, and no bugs, then add up as you go. By starting with less you will get feedback, be able to fix things fast, and know what features to add first.

Last words

When it comes to startups there is no definitive way of doing it, there is no recipe for success, so don’t regret any decisions you’ve done in the past. Past is only there to learn from, you can only become better when you learn from it.

September 22, 2012 - No Comments!

Lessons from Exercising

Why you do it?

Before you start you have to understand this Failure is an option. You keep trying to break your previous record and most of the time your fail, whether your doing handstand, lifting 200KG, or running 5k, maybe you will do it from the first time, maybe not. The thing is it doesn’t matter, you do it because you love to do it, not because you wan’t to achieve something. If it comes along the way — and sometimes it will — thats fine, but if not you won’t regret the time you spend, and you won’t identify it as a wasted time.

Problem with having a goal to achieve is that goal is based on your current state and your current environment variables, change that and you have completely different goals. Sometimes it will get very dark and you will feel that this goal is unattainable and you start to think of giving up, until you do.

Do yourself a favour, and do what you love, because you love to do it.

Start with the basics, and build on it

Before you go lifting you need to learn how to lift so you won’t hurt yourself when you add crazy weight later. Same goes for software, you need to have a strong base to build on. Having a half assed software is the worst, building a lot of features with lots of bugs, not organising code for the sake of speed. Seth Godin said: “Hurrying almost always makes it take longer”.

Take your time build a base by choosing the main feature or purpose and finish it completely, then work your way up slowly.

Don’t think. Show up

After you finish the basics all your left with is the actual work, the progress, the scary work. You show up in the gym and your supposed to lift 5KG more than your previous time, it doesn’t seem scary when you lift 20KG but when you lift 200KG it will be terrifying. At some point you will find yourself in a self doubting questions, can I really do it? is it possible? will it break my body? All you have to do is remove your mind. Thats how lifters, writers, entrepreneurs do it. They don’t think about what they are doing, they just go do it, they just show up and do their thing. If you think about what you are going to do every time you go do it, it will not end. Imagine having the same conversation over and over with alzheimer’s patient, thats the conversation with our minds are like.

Don’t think too much, just show up do your thing and get back to your life.

Work hard. Rest harder

People who exercise understand this, muscles are not made at the gym. In order to get better at what your doing you need to kill yourself at the gym then take the necessary rest to restore and rebuild your muscles, because unless you rest; you wont grow. Memory works in the same manner as muscles work, they have to rest inorder to save the data you learned and be ready for more work the next day. Not doing this will cause you overworking which will burn you out, lower your performance and get you couple of steps back.

One thing I learned from the Super Slow Protocol, you can go once a week to the gym lift till you can’t lift your keys, then take the rest of the week off and you still show progress next time.

Some people think that the more they work the better they will be, they go do it everyday, nonstop unnecessary excerption and keep whining about it. I’m not saying you shouldn’t wake all night working hard; all I’m saying it just shouldn’t be your way of life, do it when necessity calls, and do it for maximum of a week, but take the sufficient rest later.

So if it gets down to choosing between being a Marathoner or a Sprinter, what would you choose?

August 25, 2012 - No Comments!

Shopping List: Simple and fast shopping list without going crazy

Living alone is awesome, but having to go shopping is not. So I had to design a system that is easy to use, accessible, and doesn’t make me write or forget.

Here is how it works. I have one list in accessible location lets say the fridge, printed with all items I buy covered in plastic or a just get a small white board with my items and a checkbox next to each item.

The other list would be done tasks from Clear (iPhone todo application) organized in store order. So if the item is stored the first thing in the store it would be the first item on the list.

When an item runs out of stock I just mark it on the fridge list. So when I’m read to go shopping, I simply review the list on the fridge and undone the items on Clear.

While shopping Clear comes in handy, because item order matches item location on the store (assuming I buy from the same store every time), and when picking the item I can just Mark as Done.

And after going home if I bought all items I just clean the plastic list on the fridge.

August 18, 2012 - No Comments!

Getting Real Excerpt

Starting Line

Build Less

  • Less features
  • Less options/preferences
  • Less people and corporate structure Less meetings and abstractions
  • Less promises

What’s Your Problem?

  • Build software for yourself

Fund yourself

  • Outside money is plan B
  • Constrains drive innovation

Launch on time and on budget

  • Prioritization
  • Reality
  • Flexibility

Stay Lean

Mass is increased by…

  • Long term contracts
  • Excess staff
  • Permanent decisions
  • Meetings about other meetings Thick process
  • Inventory (physical or mental) Hardware, software, technology lock-ins Proprietary data formats
  • The past ruling the future
  • Long-term roadmaps
  • Office politics

Mass is reduced by…

  • Just-in-time thinking
  • Multi-tasking team members
  • Embracing constraints, not trying to lift them
  • Less software, less code
  • Less features
  • Small team size
  • Simplicity
  • Pared-down interfaces
  • Open-source products
  • Open data formats
  • An open culture that makes it easy to admit mistakes

The Three Musketeers

For the first version of your app, start with only three people. That’s the magic number that will give you enough manpower yet allow you to stay streamlined and agile. Start with a developer, a designer, and a sweeper (someone who can roam between both worlds).

Now sure, it’s a challenge to build an app with only a few people. But if you’ve got the right team, it’s worth it. Talented people don’t need endless resources. They thrive on the challenge of working within restraints and using their creativity to solve problems. Your lack of manpower means you’ll be forced to deal with tradeoffs earlier in the process – and that’s alright. It will make you figure out your priorities earlier rather than later. And you’ll be able to communicate without constantly having to worry about leaving people out of the loop.

If you can’t build your version one with three people, then you either need different people or need to slim down your initial version. Remember, it’s ok to keep your first version small and tight. You’ll quickly get to see if your idea has wings and, if it does, you’ll have a clean, simple base to build on.


Whats the Big Idea

  • Basecamp: Project management is communication
  • Backpack: Bring life’s loose ends together
  • Campfire: Group chat over IM sucks
  • Ta-da List: Competing with a post-it note
  • Writeboard: Word is overkill

Make Mantra

Organizations need guideposts. They need an outline; employees need to know each day when they wake up why they’re going to work. This outline should be short and sweet, and all encompassing: Why do you exist? What motivates you? I call this a mantra – a three or four word description of why you exist.
—Guy Kawasaki

The Devil’s in the Details

I really got over the “get into details right away” attitude after I took some drawing classes…If you begin to draw the details right away you can be sure that the drawing is going to suck. In fact, you are completely missing the point.

You should begin by getting your proportions right for the whole scene. Then you sketch the largest objects in your scene, up to the smallest one. The sketch must be very loose up to this point.

Then you can proceed with shading which consists of bringing volume to life. You begin with only three tones (light, medium, dark). This gives you a tonal sketch. Then for each portion of your drawing you reevaluate three tonal shades and apply them. Do it until the volumes are there (requires multiple iteration)…

Work from large to small. Always.
—Patrick Lafleur

It’s a Problem When It’s a Problem

People often spend too much time up front trying to solve problems they don’t even have yet. Don’t. Heck, we launched Basecamp without the ability to bill customers! Since the product billed in monthly cycles, we knew we had a 30-day gap to figure it out. We used that time to solve more urgent problems and then, after launch, we tackled billing. It worked out fine (and it forced us into a simple solution without unnecessary bells and whistles).

Don’t sweat stuff until you actually must. Don’t overbuild. Increase hardware and system software as necessary. If you’re slow for a week or two it’s not the end of the world. Just be honest: explain to your customers you’re experiencing some growing pains. They may not be thrilled but they’ll appreciate the candor.

Bottom Line: Make decisions just in time, when you have access to the real information you need. In the meanwhile, you’ll be able to lavish attention on the things that require immediate care.

Feature Selection

Half, Not Half-Assed

  • Build half a product, not a half-ass product
  • Take whatever you think your product should be and cut it in half.
  • If it doesn’t change your behavior, then it just doesn’t matter.
  • Don’t be a yes-man — We listen but don’t act. The initial response is “not now.” If a request for a feature keeps coming back, that’s when we know it’s time to take a deeper look. Then, and only then, do we start considering the feature for real.
  • Forget Feature Requests. Ask people what they DON’T want

Start With No

People kept raising their hand saying, “Does it do [x]?”, “DO you plan to add [y]?”. Finally Jobs said, “Wait wait — put your hands down. listen: I know you have a thousands ideas for all the cool features iTunes could have. So do we. But we don’t we a thousands features. That would be ugly. Innovation isn’t about saying yes to everything. Its about saying NO to all but the most crucial
—Derek Sivers

For every new feature you need to…

  1. Say no.
  2. Force the feature to prove its value.
  3. If “no” again, end here. If “yes,” continue…
  4. Sketch the screen(s)/ui.
  5. Design the screen(s)/ui.
  6. Code it.
  7. to 15. Test, tweak, test, tweak, test, tweak, test, tweak…
  8. Check to see if help text needs to be modified.
  9. Update the product tour (if necessary).
  10. Update the marketing copy (if necessary).
  11. Update the terms of service (if necessary).
  12. Check to see if any promises were broken.
  13. Check to see if pricing structure is affected.
  14. Launch.
  15. Hold breath.

Innovation Comes From Saying No

[Innovation] comes from saying no to 1,000 things to make sure we don’t get on the wrong track or try to do too much.We’re always thinking about new markets we could enter, but it’s only by saying no that you can concentrate on the things that are really important.
—Steve Jobs


  • Get something real up and running quickly
  • Rinse and Repeat. Work in iterations
  • Iterations lead to liberation

Maybe you’re smarter than me

Maybe you’re a LOT smarter than me.

It’s entirely possible. In fact, it’s likely. However, if you’re like most people, then like me, you have trouble imagining what you can’t see and feel and touch.

Human beings are extremely good at responding to things in the environment. We know how to panic when a tiger enters the room, and how to clean up after a devastating flood. Unfortunately, we’re terrible at planning ahead, at understanding the ramifications of our actions and in prioritizing the stuff that really matters.

Perhaps you are one of the few individuals who can keep it all in your head. It doesn’t really matter. Web 2.0, the world where we start by assuming that everyone already uses the web, allows smart developers to put this human frailty to work for them. How? By allowing your users to tell you what they think while there’s still time to do something about it.

And that last sentence explains why you should develop this way and how you might want to promote/launch.

Get your story straight. Make sure the pieces work.Then launch and revise.

No one is as smart as all of us.
—Seth Godin

Be an executioner

It’s so funny when I hear people being so protective of ideas. (People who want me to sign an NDA to tell me the simplest idea.)

To me, ideas are worth nothing unless executed.They are just a multiplier. Execution is worth millions.


  • Awful idea = -1
  • Weak idea = 1
  • So-so idea = 5
  • Good idea = 10
  • Great idea = 15
  • Brilliant idea = 20


  • No execution = $1
  • Weak execution = $1000
  • So-so execution = $10,000
  • Good execution = $100,000
  • Great execution = $1,000,000
  • Brilliant execution = $10,000,000

To make a business, you need to multiply the two.

The most brilliant idea, with no execution, is worth $20.The most brilliant idea takes great execution to be worth $20,000,000.

That’s why I don’t want to hear people’s ideas. I’m not interested until I see their execution.
—Derek Sivers

Do it quick

  1. Decide if it’s worth doing, and if so:
  2. Do it quick – not perfect. just do it.
  3. Save it. upload it. publish it
  4. See what people think

Though I’m always reluctant to add new features to things, once I have that “yeah!” moment of deciding something is worth doing, it’s usually up on the website a few hours later, flawed but launched, letting feedback guide future refinement of it.
—Derek Sivers

The Organization

People need uninterrupted time to get things done

The alone time zone is where the real development magic happens. Set up a rule at work: Make half the day alone time. From 10am-2pm, no one can talk to one another (except during lunch). Or make the first or the last half of the day the alone time period. Just make sure this period is contiguous in order to avoid productivity-killing interruptions.

Don’t have meetings

For those times when you absolutely must have a meeting (this should be a rare event), stick to these simple rules:
- Set a 30 minute timer.When it rings, meeting’s over. Period.
- Invite as few people as possible.
- Never have a meeting without a clear agenda.


Hire Less, Hire Late

There’s no need to get big early – or later. Even if you have access to 100 of the very best people, it’s still a bad idea to try and hire them all at once. There’s no way that you can immediately assimilate that many people into a coherent culture. You’ll have training headaches, personality clashes, communication lapses, people going in different directions, and more.

Work with prospective employees on a test-basis first

It’s one thing to look at a portfolio, resume, code example, or previous work. It’s another thing to actually work with someone. Whenever possible, take potential new team members out for a “test drive.”

Judge potential tech hires on open source contributions

  • Quality of work
  • Cultural perspective
  • Level of passion
  • Completion percentage
  • Social match

Get well rounded individuals.

You want someone who can adjust and learn and flow as opposed to a stick-in-the-mud who can do only one thing.

  • Designers who can write.
  • Programmers who can understand design.
  • Everyone should have an idea about how to architect information.
  • Everyone needs to have an organized mind.
  • Everyone needs to be able to communicate with customers.

Interface Design

  • Design the interface before you start programming. Too many apps start with a program-first mentality. That’s a bad idea. Programming is the heaviest component of building an app, meaning it’s the most expensive and hardest to change. Instead, start by designing first.
  • The interface is your product. What people see is what you’re selling. If you just slap an interface on at the end, the gaps will show.
  • Start from the core of the page and build outward
  • Design three state solution. Regular, blank, and error states


Keep your code as simple as possible

You’d think that twice as much code would make your software only twice as complex. But actually, each time you increase the amount of code, your software grows exponentially more complicated. Each minor addition, each change, each interdependency, and each preference has a cascading effect. Keep adding code recklessly and, before you know it, you’ll have created the dreaded Big Ball of Mud.

The way you fight this complexity is with less software. Less software means less features, less code, less waste.


There’s Nothing Functional about a Functional Spec

  • Don’t write a functional specifications document
  • Functional specs are fantasies
  • Functional specs are about appeasement
  • Functional specs only lead to an illusion of agreement
  • Functional specs force you to make the most important decisions when you have the least information
  • Functional specs lead to feature overload
  • Functional specs don’t let you evolve, change,and reassess

Eliminate unnecessary paperwork

Avoiding functional specs is a good start but don’t stop there; Prevent excess paperwork everywhere. Unless a document is actually going to morph into something real, don’t produce it.

Build, don’t write. If you need to explain something, try mocking it up and prototyping it rather than writing a long- winded document. An actual interface or prototype is on its way to becoming a real product. A piece of paper, on the other hand, is only on its way to the garbage can.

Tell Me a Quick Story.

Write stories, not details. If you do find yourself requiring words to explain a new feature or concept, write a brief story about it. Don’t get into the technical or design details, just tell a quick story. Do it in a human way, like you would in normal conversation.

It doesn’t need to be an essay. Just give the flow of what happens. And if you can include the brief story in context with screens you are developing, all the better.

Stick to the experience instead of getting hung up on the details. Think strategy, not tactics. The tactics will fall into place once you begin building that part of your app. Right now you just want to get a story going that will initiate conversation and get you on the right track.

Use Real Words.

Insert actual text instead of lorem ipsum. You need real copy to know how long certain fields should be. You need real copy to see how tables will expand or contract. You need real copy to know what your app truly looks like.

Personify your Product

What is your product’s personality type? Think of your product as a person. What type of person do you want it to be? Polite? Stern? Forgiving? Strict? Funny? Deadpan? Serious? Loose? Do you want to come off as paranoid or trust- ing? As a know-it-all? Or modest and likable?

Pricing and Signup

  • Give something away for free
  • Make signup and cancellation a painless process
  • Avoid long-term contracts, sign-up fees, etc.
  • Soften the blow of bad news with advance notice and grandfather clauses


Hollywood Launch

Go from teaser to preview to launch. If an app launches in a forest and there’s no one there to use it, does it make a noise? The point here is that if you launch your app without any pre-hype, people aren’t going to know about it.

To build up buzz and anticipation, go with a Hollywood-style launch: 1) Teaser, 2) Preview, and 3) Launch.

A few months ahead of time, start dropping hints. Let people know what you’re working on. Post a logo. Post to your blog about the development. Stay vague but plant the seed. Also, get a site up where you can collect emails from folks who are interested.

You should also start seducing mavens and insiders. These are the folks on the cutting edge. They’re the tastemakers. Appeal to their vanity and status as ahead-of-the-curves. Tell them they’re getting an exclusive sneak preview. If a site like Boing Boing, Slashdot, or Digg links up your app, you’ll get loads of traffic and followers. Plus, your page rank at Google will go up too.

A few weeks ahead of launch, start previewing features. Give people behind-the-scenes access. Describe the theme of the product. Also, tell people about the ideas and principles behind the app. You can also offer some special “golden tickets” to a few people so they can start using the app early. You’ll get the benefit of having some beta testers while they’ll feel that special glow that people get from being early adopters.

It’s release time. Now people can actually go to the “theater” and see your app. Get emails out to those who signed up. Launch your full marketing site. Spread the gospel as much as possible. Get blogs to link to you. Post about your progress: How many people have signed up? What updates/tweaks have you made? Show momentum and keep at it.

A Powerful Promo Site

  • Overview: Explain your app and its benefits. Tour: Guide people through various features.
  • Screen captures and videos: Show people what the app actually looks like and how to use it.
  • Manifesto: Explain the philosophy and ideas behind it.
  • Case Studies: Provide real life examples that show what’s possible.
  • Buzz: Testimonial quotes from customers, reviews, press, etc.
  • Forum: Offer a place for members of the community to help one another.
  • Pricing & Sign-up: Get people into your app as quickly as possible.
  • Weblog: Blogs keep your site fresh with news, tips, etc

Name Hook

Give your app a name that’s easy to remember. A big mistake a lot of people make is thinking their app’s name needs to be ultra-descriptive. Don’t worry about picking a name that vividly describes your tool’s purpose; That usually just leads to a generic, forgettable name. Basecamp is a better name than something like Project Management Center or ProjectExpress.
Writeboard is better than CollaborEdit.


Feel the Pain

Tear down the walls between support and development. In the restaurant business, there’s a world of difference between those working in the kitchen and those out front who deal with customers. It’s important for both sides to understand and empathize with the other. That’s why cooking schools and restaurants will often have chefs work out front as waiters so the kitchen staff can interact with customers and see what it’s actually like on the front lines.

A lot of software developers have a similar split. Designers and programmers work in the “kitchen” while support handles the customers. Unfortunately, that means the software chefs never get to hear what customers are actually saying. That’s problematic because listening to customers is the best way to get in tune with your product’s strengths and weaknesses.

The solution? Avoid building walls between your customers and the development/design team. Don’t outsource customer support to a call center or third party. Do it yourself. You, and your whole team, should know what your customers are saying. When your customers are annoyed, you need to know about it. You need to hear their complaints. You need to get annoyed too.

Publicize Your Screwups

If something goes wrong, tell people. Even if they never saw it in the first place.


  • Issue a major update 30 days after launch
  • Keep the Posts Coming. Show your product is alive by keeping an ongoing product development blog post-launch. Things to include (Faqs, How-tos, Tips & tricks, New features, updates, & fixes, Buzz/press)
  • All Bugs Are Not Created Equal. Prioritize your bugs (and even ignore some of them)
  • Go With the Flow. Be open to new paths and changes in direction

Start Your Engines


Everyone can read a book. Everyone can come up with an idea. Everyone has a cousin that’s a web designer. Everyone can write a blog. Everyone can hire someone to hack together some code.
The difference between you and everyone else will be how well you execute. Success is all about great execution.


You need people who are passionate about what they do. People who care about their craft. People who take pride in the work, regardless of the monetary reward involved. People who sweat the details even if 95% of folks don’t know the difference. Anyhow, when you find those people, hold onto them. In the end, the folks on your team will make or break your project - and your company.
More than just software

More than just software

It’s also worth noting that the concept of Getting Real doesn’t apply just to building a web app. Once you start grasping the ideas involved, you’ll see them all over the place.

Sure, Getting Real is about building great software. But there’s no reason why it needs to stop there. Take these ideas and try applying them to different aspects of your life. You might just stumble upon some neat results.

Grab a Copy

This is one of the best books that I have enjoyed and learned from. You can buy the book from Amazon Getting Real