I certainly understand the reluctance to add a/new programmer(s). Adding people (initially, at the very least) is always a complication. If you don't have a person you know-and know well-in mind then 'finding' and 'selecting' a new coder alone is difficult, needless to say getting everyone to work well together... however, that doesn't mean that Robobob would need to take on the role of 'manager'. He could, if he chose, remain a full time developer and hire someone else to be a manager. This may seem odd to some, but 'tis better to hire someone apt to the job than to needlessly take on the role yourself just because you 'own' the business.
With respect to adding more coders adding complexity to the coding process... yes, this is true, unless you take into the fact what absolutely EVERY coding class teaches, which is that all modern languages are designed to allow multiple different coders work together without stepping on each other's toes. It doesn't matter if programmer X uses method Y and variable names A, B, C in their coding... programming is modular-unless programmed idiotically, in which case you get extreme issues of bugs and difficulty making changes (I won't name names...)-and therefore can be done with as many different people as one desires.
Robobob could add another coder, give them a separate task to work on and only check to see if the combined code works together (heck, we will notify you all if there are bugs, so he could even ignore that aspect). If it turns out that the new coder produces far too many bugs-by way of bug reports and the new developer's designated tasks-then Robobob could 'have words with them'... or, as mentioned before, hire a manager to do this for him...
Ultimately, though, it is all up to Robobob. It's his program, what he wants with it is what will happen with it... all we can do is make suggestions (and argue our points).