1. Less Money Times have changed. All other people’s money gets you these days is into debt. And that’s not a great place to start anything from. You don’t need money for hardware — hardware is cheap. You don’t need money for software — software is free. You don’t need money for marketing — there are a variety of ways get your message out online to a huge audience for next to free. Money doesn’t buy you time and money doesn’t buy you passion (and passion is something you need a boatload of). All money buys you are salaries. And salaries buy you people.

2. Less People For companies trying to build new web-based businesses and web-apps, all you need to start is three people. Three people to launch a product. A programmer, a designer, and a “sweeper” — someone who can move between the worlds and also gets common sense business and marketing. Don’t scale up your headcount to match your proposed feature set and vision, instead scale down your feature set and initial vision to match your headcount. The less people you have the less time you have.

3. Less Time Your competitors have 10 people at 40 hours a week (400 hours). You have 3 people at 40 hours a week (120 hours). Sounds like a disadvantage, right? Nope. It’s a huge advantage. The majority of time you spend working is wasted time. Too many meetings, too much planning, too much thinking, too much writing official documents. The more time you have the more time you have to waste — and it’s likely you’ll waste more than you use. When you have less time, you’ll spend it more wisely. Think about time as money: If you only have $500 in the bank, you’re not going to spend $400 on a TV. You’re going to be careful about spending your money. If you have 40 hours instead of 400, you’re going to spend that time more wisely. More value per hour for your less time.

Further, people are often wishing there were more hours in the day, more days in the week, and more weeks in the month. You don’t need more time, you need less time. In fact, instead of working 40, 50, or 60 hours a week, consider capping your time on your core development to 20 or 30 hours a week. You’ll likely get more real work done.

4. Less Abstractions The best way to deal with less time is to do less paper work, less busy work, less abstracted work. This means do less stuff that isn’t real. Less boxes and arrows. Less charts. Less documentation. Less stuff that is abstracted from the real thing — the real product your actual customers will see.

And the #1 abstraction to do away with is the functional spec. I won’t repeat myself — just read Getting Real: No functional spec.

5. Less Software All this less stuff leads to one key point: Less Software. When you have less money, less people, less time, and less abstractions, you’re going to be forced into developing Less Software. And that’s a great thing. Less Software allows you to distribute your time and energy across less features. More attention to less stuff will make that less stuff better. 100% of your time across 20 things via 100% of your time across 10 things will result in a very strong 10 things. And that’s the kind of software that is satisfying to build, and satisfying to use: simple, focused, useful software that’s really polished. And that’s how you win these days.

6. More Constraints I said I’d discuss five things you need less of, but there is one thing you need more of: Constraints. All this less is really about more constraints. That’s where you’re forced to be creative. That’s where you’re squeezed to make better use of your money, your people, your time. And out of this squeeze will come better software, more satisfying software, and simpler solutions. The truth is this: There are a million simple problems that need to be solved before you should even consider trying to solve the complex ones. Less software solves simpler problems. Let your competitors kill themselves trying to solve the big complex problems. Solving those problems are really hard, really expensive, and riddled with bad odds. Stay simple, build simple, and solve simple.

UPDATE: Notes from my talk from Robert Kaye and an article from ZDnet.