I understand there is plenty of information on the internet about planning and implementing said solid plan in building a large software application, but I was hoping to get something a little more specific to aid my approach for this specific instance.
Some Background:
We're a web hosting company that has a team of 3 developers. My colleague and lead developer has been with the company a few years, and up until myself, and another developer were hired, he was the sole one looking after all the company's projects.
All three of us have very little experience in leading a team, or even working with other developers in a meaningful sense. We've all come from small business backgrounds where input has simply gone in our ears, and code has come out.
There's some benefits to our position as well; our team is fairly autonomous. Apart from a few directives given by management, we have total control and freedom in managing our projects, deadlines and the tools used to implement our solutions. It's a pretty great gig, but we're all around the same age (early-mid twenties) and so there's not so much team-lead experience there.
The Application:
Our current billing system is the oft maligned WHMCS - which is a plight of many other hosting companies I'm sure. As a result, we've been tasked with designing a replacement that has all of the features we need specifically for our operations.
At the start of the year, my lead developer began working on it. This was the traditional case of 'begin prototyping and see what happens'. While his code was great, and the foundation solid, there was zilch going on in terms of scoping (the designer hadn't even looked at it yet), and now the code base is starting to creak under it's own weight, and it's barely a third done.
Me:
I've come along from a small web design business where I was considered the 'go-to' guy, so I took it upon myself in many instances to attempt planning a project that more than once has saved the profit margin from dipping into the red. This has helped a little in convincing the lead developer to adopt a more careful, structured approach that allows us to work as a team, and have this quite critical piece of software not be a steaming mess of bug fixes and hacky patch-ups.
I'm a journeyman developer, so I'm not well versed in best practices, I don't know three or five or ten programming languages, but I can code. And I'm a great communicator (in real life, not when writing questions like this ~_~), so I hope what I learn here will be able to directly translate into something that benefits our small team.
The actual question:
For a big old 'TLDR;' here: What are the preferred methods of planning a large codebase? We're our own masters in this, so we have no guidance. Muchas gracias in advance!