Jr/Sr to me is more about skill levels than raw amount of experience. To me, the mark of a senior person is the ability to take a problem down from the conceptual level, decompose it, plan an architecture which solves it, and (if the person is a team lead) get other people into consensus around the solution by showing them why it works.
Junior people are the ones who require others to walk them through that process - either because they're new to the field, haven't been exposed to those types of problems before, come from different environments, etc. Jr. people are midrange investments - the ones you look at and say "Let's invest in this person's growth, because he or she can become really strong with some mentorship and practice". And then you get a senior developer to agree on that too, since the task of mentoring will mostly fall on that person.
By that definition, I have to agree with Jonathan: it would suck to come on at that level without someone more senior to provide mentorship. Some people would thrive in that type of "knit your own parachute before you hit the ground" environment, but many wouldn't do so well, and that would hurt both their own skill development and the company.
If someone is already cranking out complex software without hand-holding and you like how it's working (e.g. good, solid code with few bugs in a reasonable amount of time), that implicitly means the person is at least mid-level, possibly senior, and is probably someone you want to consider for your early team (particularly as you know the person and there's already a good history of working together in place).