When I've worked with companies that were very ad hoc in methodology, we looked at the top two or three process or infrastructure issues that mattered "right now" and started investing time in them alongside our normal commitments.
I don't think traditional "software engineering" is necessarily the right model for a small team that's dealing with frequently changing business requirements; software engineering is more important for dealing with multiple vendors and situations where change is very expensive and needs risk and quality gates. If you're building software for space shuttle parts or cars, the software engineering approach may make sense.
Instead, I advocate a "software craftsmanship" approach for most organizations. But software engineering has created tools and discovered processes that work for lots of kinds of teams, so I am not saying that you should ignore those lessons, just that you should work from a different perspective that's more about continuous improvement, dealing with ambiguity and change, and taking a couple of hours every month or so to do retrospectives on what's working well and what's not working well with your development and business processes.
In your shoes, I'd say you can probably not worry about UML for now; you need to focus on getting a lightweight version control system into place. Just start with Git or Mercurial, and either sign up for private repositories with a third party vendor to push your repositories to (Bitbucket, Github), or set up a local server to push to.
Then worry about setting up a continuous build system (like Jenkins).
Small teams may not be able to afford full time testers, but they can start building automated unit test coverage; even starting this practice without religiously adhering to any particular methodological dogma may help you start writing new code in a more maintainable state, because you'll get annoyed enough by any friction in writing tests that you'll either want to fix your code or give up testing. If you've got the other stuff in place, and you start to get even the slightest value out of testing, you'll probably prefer to fix your code rather than give up testing.
You can do this on your own by just investing time in it. It may be worthwhile to hire a person to work on either your infrastructure or process problems, but the three items above are usually low hanging fruit that will show immediate returns and require relatively minimal investment.
As for books, read the Pragmatic Programmer, Software Craftsmanship: The New Imperative, and any of the books available on distributed version control and continuous integration. You should evaluate Extreme Programming, Scrum, and Kanban to see what you think will work best for your team . To get better at process, attend local meetups or events with other small software shops and talk about what's working and not working for you, and get better ideas from your peers on how to cope with high velocity with small teams. Software Engineering isn't really about maintaining velocity, it's about maintaining control of things that interact with your product.
Once you have a 5 person team, though, some sort of process management help makes financial sense for most organizations. Hiring a program manager or ScrumMaster or something along those lines will have some value to your founders if it will help you deliver work more consistently and predictably.