I am software developer and am currently happily leading my team of one... me.
The problem is that my responsibilities and quantity of work is starting to balloon and I fear that it will soon become unmanageable and that the quality of work will suffer. I strongly believe that I could build a team to do this.
I suppose the question is how would you present to your directors that you think to do your job effectively and deliver the best products you can that your team of one needs to grow?
You are asking us to take it for granted that adding more labor is a good idea. For reasons that I describe below, my prior belief is that growing a team in response to "ballooning" workload is often the first sign of trouble. If I were in your position, I would try to talk with my manager about why the work is ballooning -- and to try to hash out some clear software specifications, use cases, tests, and feature planning that should scope out the space of work that should be your responsibility. If you can work with your boss to constrain and limit the unplanned growth of the project, the constrained product will usually be vastly better.
I like to think of it like a city planting some trees along the sidewalk of Main Street. You can let the tree grow unchecked, in which case it might crack a bunch of sidewalks and require you to hire a bunch of people to maintain the side-effects of growth. Or, you can tether the young tree to a post and guide its growth with a severe and ruthlessly rigid plan of development -- and you get pretty, straight trees with less broken-sidewalk risk.
More to the point, in some widely-cited software best practices books, such as The Mythical Man-Month and Peopleware, it is often described as a fallacy that adding more labor-power to a software project will add good results.
Obviously, there are capacity limits surrounding what a single person can do. But figuring out when and how to expand the team is not trivial -- and expanding a team merely because a developer (or group) "feels like" the work is becoming unmaintainable is not always a good idea.
Without an architectural plan about how the work is likely to grow and change in the future, throwing more cooks in the kitchen usually creates problems. For one, the initial cost of a new person is usually much higher than budgeted. Here I mean in terms of ingesting and training new people. And even after the person ramps up and begins adding a net positive productivity effect (months later) you then have an additional communication channel which reduces everyone's overall productivity -- and you have additional managerial overhead.
In general, since there are N*(N-1)/2 two-way connections between N people, it means communication overhead grows as the square of the team size. Often managerial bureaucracy grows at the same rate or faster. Quickly, the original arguments about lack of labor hours will intensify in a feed-back loop, whereby adding people to alleviate workload pressure thus causes enough new workload pressure than the marginal value of a new team member is too low (or even negative!) to do it.
Many people naively think this only happens when you're talking about NASA scale projects with hundreds of engineers. But, in fact, it can happen in a team with as few as 2-5 people. It all depends on the infrastructure, the development needs, and the architectural plan for what the software roles are needed to accomplish.
I would say to read the two books mentioned at the top of this answer. Reflect on how you might 'architect' a plan of attack for the project as you see it now, taking pains to account for as many different (possibly unanticipated) directions of future growth as you can. Read about planning fallacy. And then try to synthesize all of that into an actionable plan for growing a team.
