As a sole founder, you must be able to work for a long period of time without feedback from anybody. It is very isolating. It is also very easy and tempting to give up halfway, and just start doing something else, in which you get more feedback from other people.
I find it much easier to find a suitable co-founder, who has a plan, and then just join in, than to get someone else to join in on my plan. For me, it has always turned out harder to motivate someone else for my idea, than to motivate myself for someone else’s idea.
Given my background, I usually do the programming work in a start up. What do I always need? Someone who validates the programs.
Someone who picks a program and compares for a given input, the expected output to the actual output. The internal structure of good software consists in small programs that communicate with each other, often across network links.
The co-founder must be able to use the command line and execute these individual programs in order to validate their output. Some of this work can be automated with unit tests at the very lowest level, but most of the validation work cannot. Furthermore, it is not enough to just pick the final user interfaces and start testing there. At that level, problems are already hidden behind several layers of abstraction.
Verifying the emerging platform for discrepancies between expected -and actual output are the much needed feedback that keep the project going in the right direction.
Testability of the smallest-possibly bricks, is the overruling concern in the architecture of the platform: If I do this, then that should happen. All other concerns are relatively unimportant. For example, I will never make some program go faster, if doing so badly damages its testability.
WordPress is the prototypical example of how NOT to build software. What are the smallest testable bricks in WordPress anyway? The only way to validate its functionality, is to test the final user interface. That is not the way to obtain quality results. Quite a few developers mimic that kind of architecture, often by using elaborate frameworks. It does not work for them. It only works for miraculous super-programmers, and even then, it often fails.
There are other things to do in a startup, such as arranging funding (raising capital if needed), monetization (getting revenue streams going), and recruitment. These are less important issues, however, compared to the badly-needed feedback and validation. I would be weary of a co-founder who does not want to make his hands dirty and who refuses to spend hours in a row, again and again, validating the platform that we are building.
I think that for most people, the minimum realistic head count of a beginning startup is two. It could be more, but with every additional person, the communication overhead grows, and things may also depend too much on a consensus that could be difficult to achieve. Therefore, I think that a startup are best two people who manage to get along sufficiently well, and who are sufficiently complementary.
Programming is indeed done in pairs, but not in a way as proposed by the Agile methodology. There is no point in both people staring at the same screen simultaneously. It is more an issue of making sure that someone verifies the consistency of the platform from its smallest bricks all the way up to its user-oriented levels.
I personally never look for a job, because in fact that means looking for an employer, and an employer will not make his hands dirty. I’d rather look for a co-founder instead.