SXSW: Design Aesthetic of the Indie Developer

[Notes from this panel with Nick Bradbury, John Gruber, Shaun Inman, Michael Lopp]

Indie development is where the cool happens, it's where the great ideas come from.

So let's start with some context.

Developer

The goal of the developer is changing. What is great about SXSW is that designers and developers are hanging out in very meaningful ways. Everything is blurry here. Most in this room are a little of both because the lines are blurring in the whole industry. This is the present and the future of the web.

Death of the start-up

Indie developers aren't as interested in the IPO. Now we have companies that are fine as three people. Getting boughts isnt the driving philosophy any more.

Level playing field

Mindshare is truly egalitarian. Dig and Boing Boing and all these other sites shoot people from zero to hero in no time at all.

It's a small world

So what's design?

No way can we define that. But that doesn't help so what is it.

See: Architecture of Architects

The iPod giggle is when you give someone an iPod and they just start to use it. When people figure out the little things about it they have a genuine emotional reaction, they giggle.

Design is a pile of iterated decisions. This isn't trivializing, this is really hard. You want to through out 80% of your ideas.

A set of guiding principles underlying and guiding the work of a particular artist or movement.

So what about Indie?

These developers are building for themselves. They are scratching an itch, solving a problem for themselves.

So what are the lessons learned from this kind of indie development?

How do you make hard decisions as a lonely developer?

Start with how you would like it to work. It sounds selfish but if you are building something that you need, you should take yourself seriously as a user. Blog about what you are doing and take comments seriously.

Anything that ends up being successful is something that started as a problem that obsessed the developer. It doesn't matter if you are in your pajamas, it is something you are thinking about from morning to night until it is a solved problem.

Conversation with people who share your interests or who are using an early version really helps to whittle down ideas to see if they fit.

So what is the dev cycle? Do you use spec?

It always starts on paper. Get a new notebook for the project and start drawing sketches. Wait until you see one that you'd really like to build.

Start with learning. Don't worry about having the skills required, don't let your skill-set limit your solution. Find a problem, find a solution, and then learn the tools you need to build it.

Build it twice. Start writing hackish code to learn from as you go and then throw it away and build it properly.

So when you need to bounce an idea off of what do you do?

It's much easier now than it used to be. Blogging makes it so so much easier. You can write about a feature before it exists and get feedback on it.

It depends. Sometimes you just use your iChat buddy list to get feedback on a spark of an idea. Scan the list and see who might have something interesting to say about what you are trying to do.

People who you know are a real asset, they will give you honest feedback.

If you do your own support you hear the problems first and can fix them since you do that too.

What constraints come with smallness?

Time is the biggest constraint. If you are working for a bigger company you have pressure to ship from someone else. When it is just you there is nobody else to blame. If you fail it is you.

What lessons from big corporations influence indie work?

Proved that doing indie development was better. In corporations there is less direct contact with users, it is sometimes harder to give them what they want.

If you aren't a team player, if things stay in your head, it is easier to be indie.

How do you measure success? Revenue, buzz?

Buzz is part of it but if nobody says anything it might mean that you are successful. Most feedback is negative.

Most success is hindsight. You look back and see how it went and realize if you were right or wrong. It depends how long this takes. It could take a month or longer.

Insulating yourself from a large audience is important. A polarized audience can be good. If half love it and half hate it you have people to learn from and you have an audience that really cares.

It's a like playing in a live band. If the audience is sitting down you are doing a bad job. At a corporation it's like being a studio musician where you don't get that immediate feedback.

What need would you hire to fill?

Sending t-shirts out.

Support is a serious issue because you want to get every question answered but you don't want to be separated from the users.

Once you get enough users where the income is enough to be a business you end up spending your whole day supporting them instead of coding.

How do you structure your day given that you are working at home?

Structure the day around kids. Take them to school, come home, and get to work. Having an office that feels like you are in your own world helps.

Working at home can be a blessing because you get to see your family all the time.

You do get more interruptions, and with kids they are normally not the kind of interruptions you get in an office, but you do get interrupted in an office setting too. Just like in an office, if you need to shut out the world just close the door.

The biggest complaint about working at home is that it is more tempting to work too long and not to call it a day.

When you are in an office you get to go home and be done. This is really hard to do at home if the flow is going. You should stop but there is nothing there to force you to stop.

You could wake up at 3am with a great idea and just start coding. You won't do that in an office.

How do you manage the risk of supporting yourself with your development?

As a salaried employee it is too easy to lose sight of the goal. If it is all on you then you can't stumble, you just keep going.

If your development emerges from your other freelance career you can fall back on that. Mint and Basecamp were both born as side projects.

Was there a moment where you decided that your work was success?

Went Mint launched within the first week it far exceeded expectations. At this point he had to start turning down freelancing gigs.

Do you have an exit strategy? Do you want to get bought or is the goal to stay small?

If you really like being small you should stay small.

There is a great quote from Walt Disney.

I don't make money for the sake of making money. I want to make money so I can make more pictures.

The point is to do what you want to do. Follow your tangents and keep doing that. If you are better on your own, stay that way.

The goal is not to make it big and then stop for the rest of your life. The goal is to keep doing what you love. More money just buys you a bigger monitor to work on.

How do you compete with larger companies who have more resources?

If you are smaller you can be quicker. You don't have meetings to decide on features, you just build them.

You also don't tend to target larger markets. If you are small you can find a niche and make it work enough to keep you going.

With Mint the differentiator is design. It is an opinionated application and if you have a different opinion it isn't for you. The business model doesn't need everyone to love it. Google Analytics can't compare to the simplicity. Most people in this room use Mint for a reason. You look at it and it feels better. The best way to sell Mint is to compare side-by-side.

Google Analytics is for a different market. Mint decides what is important and shows you that. Google Analytics shows you raw data, Mint presents formatted data as information.

There are tons of free feed readers but there is a reason people use FeedDemon and NetNewsWire, they are just nicer. If you don't see the difference the product isn't for you.

Design or code first?

Always design first to get to the simplest solution. There is the wireframe part of design but then there is the question of skinning. Just making it blue doesn't change the interface. You want to have an interest in both the interface layer and the graphic layer. You want to build them to work together. It is a combination of how it feels and how it thinks.

Where do you draw the line when you listen to haters?

You just have to use your own internal compass to decide what is and isn't helpful. If you are your own user you know what will and won't fit. People want multiple user logins to Mint but this would open to a new market that just isn't right for the application.

You have to listen to the people with complaints and requests. The people who love it don't have any help to offer. You have to listen to the complainers but still be ready to say no more often than not.

Complaints are kind of a compliment. Someone is saying that they like your product so much that they want to make it better.

Have you ever had a feature emerge from an argument with a user that you didn't want originally?

You fight it and fight it but if your beta testers are clamoring for something give it a try and see what happens.

When building Joyent the idea was the email, calendars, and contacts would be shared with the team. So should things be shared by default? The original inclination was to be private by default but this didn't fit into the vision. The idea is that this is team email and they built it to be open and it is just smarter. They realized that if you see email as part of the teams work instead of individual silos you get to a totally new way to collaborate.

So you like to follow your tangents. Are you afraid that you won't have time to follow the next tangent because the first one has gotten too big?

That is always a fear but the original fervor will settle down and you'll have time. If you really get tired of something just open source it or sell it to someone else.

Where do you find inspiration?

Copy the things you admire. Find a small problem that you have and try to solve it.

Start small with something you intend to give away for free. You will learn lessons this way and can then move on to something better.

Do you have any strategies for avoiding pitfalls? How can you efficient while throwing things away as you go?

You can't do it without making mistakes and then starting over. You have to find the failures through trial and error.

Think of the first try and a distinct thing. Code to learn. Throw it away. Write it again with great commenting so someone else can read it.

If you get too invested in the first try it gets too hard to throw it away. Fail early and often.

What kind of mechanisms do you use to communicate with users? Forums, blogs, direct email?

Started with email support and this was a terrible mistake. It is totally unmanageable for one person.

Web forums are the best way to do this because you don't have to answer the same thing a thousand time and you can build community. Blogs are useful as a FAQ.

Forums only work once the bugs are worked out but when you are asleep misinformation can spread and you'll have to clean it up the next day. The same symptoms can represent different problems and you have to work hard to keep the communication clear.

The best thing you can do support wise is to try to anticipate where the pain points are in the application. If something is too complicated to use and support just don't do it to begin with.

How do you determine pricing?

It depends on the product and how quickly you want the user base to grow.

Your instincts are probably wrong, they are probably to under-price. Look at what other people are doing and fit yourself in deliberately.

Make it more expensive than you think it should be. If your product is too cheap people think it is too cheap. Pricing higher can set you up as a quality product. Cutting the price later is much easier than raising it.

You have to take maintaining the product into account. Don't promise free upgrades for life.