Regardless of if you are a half-man team or a 200 man team you need to be clear about what your goals are. Which mean yes there must be project management.
Now you don't need to draft a two hundred page word document with signatures, and graphs, and links to further reading. In fact please don't do that.
But you do need to be clear about:
- where is the solution
- why you value the solution
- who is responsible for the solution
- how you wish to travel to that solution
- when you wish to arrive at the solution
- what tools will help you arrive at the solution
- which paths to that solution are you using
Those are not easy questions to answer. But you will need to answer them, and the answers will change overtime.
Knowing where the solution is will help you in evaluating off the shelf vs. cobbled together vs. in house solutions. Do you pay for an SQL Server licence, use MySQL, or write a dedicated persistence library? If your solution exists in the high availability category then it makes more sense to use SQL Server, or MySQL. It is doubtful you could write something more available. If you are in the embedded space then it might pay to role your own, as you can tailor exactly what you need. Without knowing where the solution is, you will make the mistake of putting go kart wheels on a rocket car, or building a lead balloon.
A solution is really only ever as good as its reason for existence. It might be well crafted, and a dream to install, but if its utility is once a year to replace a 10 second task it isn't very valuable. Knowing why the solution is needed will help you focus on making something beneficial. Without knowing you can only be useful by accident.
Responsibilities. Who decides when you work? How long you work? When you will work? Can you be called for support during your lunch break? Who makes the call about spending money? Who decides what the development process is? Who will arbitrate when a disagreement occurs? Right now she is your friend, but when you are discussing work, who is she, and who are you? Make sure the responsibilities are clear, you don't want to lead her on, but you also want her to know what you a reliable for. Also be clear about Who you will be expected to be. Are you comfortable acting as a manager? It is a different set of skills to developing software.
How are you going to work on this? Are you going to following TDD, BDD, some other design process? How are you going to allow parallel work? (Even by yourself chances are you will be asked to change focus, how are you handling the not yet production ready branch?) How are you tracking bugs, features, tasks? How are you demonstrating work achieved? How are you maintaining the operational system? How are you going to handle a bad deployment? When you answer how, you need to be aware of what you value, because how could be to write quick, dirty code. If you value good clean code, this is a sure-fire way to become dissatisfied, and will lead to you hating the code. Save yourself the trouble, hold yourself to what you value.
Odd, but businesses like to know when something will be achieved. So that they can schedule in all of the other whens that need to be achieved to get what they call a business value. Sometimes they need to do training, sometimes advertising, sometimes a booth or a demonstration. So part of this is projecting forward when things will be ready, and keeping the business up to date with that. So when are these big milestone likely to happen. Make estimates, and update them regularly. Play around a little and work out what system helps your estimates to be most accurate.
All of those what's that go into actually making, and operating software. There are a lot of them. They include everything from the code editor you will use, through to the domain name service, the printer, to the gui library, all of those "free" packages, etc... The specific what's will change, but you still need to know roughly what they are, or how to learn what they currently are. If you don't know it will be hard to make provision for a new developer. Oh, you need this credential, that runtime, oh and of course don't forget to install xyz. It also makes it difficult to create and maintain the prod and test systems, any automated tests, source/code versioning, project management, etc... I personally keep a tight reign on them by treating as much of these tools as code as possible and keep myself honest by rebuilding the various servers regularly from that code. The rest live in documentation with a regular scheduled review date twice a year.
Finally, which way are you headed right now. This is the short term objective inspired by all of the previous answers. Its a quite technical answer about your current activities. If you are comparing vendors then this would be compare vendors against these criteria. If you were bug hunting, it might be identify bug source, generate at least three solutions, evaluate against criteria, and schedule fix. Or maybe its implement these features, etc...
Old saying my dad used to say a lot: Move quickly, not fast.
Anyone can move fast, just run - you will probably hit a wall or run off a cliff, and given how many directions there are, you will be running in the wrong direction, but boy are your legs moving!
But moving quickly means understanding the situation, identifying several paths, comparing the paths qualities, and picking the best solution in context. You may have to circle back later, but when you do its not because you were stupidly making work for yourself, its because the environment changed in a way you could not have forseen and hence was work you would have had to do anyway.
Would you buy a car that was assembled directly from an engineers stream of consciousness?
More importantly would you willingly sell a car that was assembled directly from your own stream of consciousness?
I personally wouldn't, even if I had some cyborg-augmentation that gave me access to the schematics of all previously constructed cars. At the very least I would assembly ten of them and test them first to prove to myself that those schematics were correct. I would assemble various sub-assemblies for various tests as well. And I certainly wouldn't sell if I couldn't clearly communicate how that car should be operated, and how it should maintained.
Essentially, don't be stupid. Those tests, that documentation, the schematic documents are there for a purpose. They are created precisely to address the issues you highlighted:
- High level schematics enables fast growth as it lessens the learning curve from impossible/hard to hard/managable.
- Tests provide a safety harness to alert the unwary to unexpected changes
- Documentation provides curated knowledge enabling others to make wise decisions
And most importantly its your own mindset about these activities that forms the basis for the culture that later software developers will inherit and live in. Which code base will be your legacy?
Will future developers inherit well designed code, with supporting and up to date overviews, tests that are sound and legible, with documentation that captures the design choices and their reasonings?
Or are they going to get an unintelligible mass of code?
Jenkins, like any other tool, it is only useful when it fulfils a purpose.
I'm a one man team too. I use Jenkins because I need a scheduler. It:
- refreshes my SSL Certs,
- runs daily verification builds to identify out of date packages and security issues,
- runs my official builds because I can't be bothered to wait the ten minutes for Docker to download the latest images when my server can do it in 2 minutes, and provide a pretty unit test graph.
Not that I don't have the ability to do all of those things manually by running a script.
You will be branching, and more than likely merging too.
You will have:
- emergencies come through,
- larger features that need more bake time
- features that are done, but have to be delayed as they are breaking, or need business sign off.
- development script changes that need to be pushed into all of these branches to keep things ticking...
Not to mention, and you said it yourself, the need to be ready to hire 4 other developers. You will need to know how you are going to branch before they make a mess of things.