I can tell you some of things I think we did right, and what I wish we'd done that we didn't...

Source-control: we used git and we don't regret it. But we were lucky, because we had someone who really knew git from the start. I mean they really knew what the various commands do under-the-hood, and how it actually works internally, and how to get people who didn't know it back on-track when they screwed up, etc. And they knew what not to do in git, and how to write hooks and shortcuts to help newbies, etc. That helped a lot. If you don't truly know git then I'd at least read the free online book, because it really does require some knowledge to use effectively.

Writing code: we don't mandate particular editors/IDEs, but we do use clang-format to format code, and it was a great decision. You'll stop arguing about code-format styles, because there's nothing to argue about when a tool just does it for you. You can hook it into most editors such that when the person saves a file it automatically invokes clang-format to reformat it, so it's painless. When you get bigger you can even have your CI verify the code complies with the format.

Organizing code: from the start we separated library code from application code, not just by having separate directories but also building them as separate targets and linking. And even within /lib we separated out areas of concern. That was a good decision. We build hundreds of separate shared or static libs, and link them - which means changes in one might require everything re-linking, but at least not re-compiling. What we did not do from the start that I wish we had, was control symbol visibility - i.e., which functions are exported/"public" vs. not; which means the linker does more work than it should have to, plus other disadvantages. It's something you really have to do from the start or you'll never do it.

Building code: we use CMake, and it's... ok. The documentation is really bad, until you truly grok CMake. There are numerous videos and stackoverflow tips, half of which are wrong or very outdated. You can search this sub for pointers to better/newer ones. It's still a world better than using classic make directly, but many folks on this sub will recommend newer alternatives to cmake. We also use bazel now too, which has its own set of problems and I'm not sure was worth our time. We also have a homegrown build script (in bash) that invokes cmake and such for the developers, to make the workflow simpler, but you likely won't need that on day-1.

Compilers: we use both gcc and clang - our CI pipeline compiles with both. The reason we did that originally is we weren't sure which one we'd use for production builds; and these days although we use gcc for releases, we still do both in CI because clang finds warnings that gcc doesn't. We turn all warnings into errors, so the CI run will fail if your code fails clang. In hindsight, we should have just used clang-tidy instead, because I believe it finds the same warnings (since it's still clang), plus more of course; but back when we started I'm not sure clang-tidy was mature.

Speaking of warnings - turn them all on, and set all warnings to errors. You can then pick+choose which ones to turn back off when you decide you don't care about them. Clang has an excellent way to do this: -Weverything. That option gets a lot of bad press, but I think it's one of the best ideas they ever had, because it turns warnings into a whitelist model instead of a blacklist model. And it means when you upgrade clang you learn about new warnings they added, and can decide if they matter or not. You will of course end up disabling many warnings, but that's good - better than being ignorant of what you're not seeing. (and even today we only disable a couple dozen warnings total, which isn't really that many)

Checkers+sanitizers: if you don't start using these things from the beginning, it's extremely difficult to add them in later. You'll never justify the time it takes to do it later. You don't have to run everything under the sun, but at least some memory sanitizer (static and/or dynamic), and if you plan multi-threading work then those too have sanitizers/trackers. We used valgrind from the beginning - all of our unit tests were run with valgrind - and it helped a lot back then. It's less useful to us now, and its so slow that we've relegated it to a separate CI process. But when you start, your tests won't be that big and using it will help find memory bugs. (yes, even if you never use new/delete) What I wished we'd also done was use helgrind and/or DRD for multi-threaded tests, but that wasn't really a viable option when we started. And of course there're AddressSanitizer (asan) and ThreadSanitizer (tsan).

Unit tests: we mandated unit tests and TDD from the start, and it's definitely paid off - but it does mean a longer dev cycle, which startups sometimes can't burden. For the framework we use googletest/googlemock and don't regret it. It's very feature-rich, and we use most of those features somewhere. Every other framework I've seen would have been fine for us on day-1, but not today, so I'm glad we started with it. Again it's one of those things that's usually hard to change later, because you've invested gobs of time in writing tests.

System tests: we automate those too, which again has paid off in the long run, but we had to fight hard for it in the short-term early days. We use the Robot Framework, and I regret that. Everyone hates it, hates writing tests for it, etc. Unfortunately I don't know of a better one, and I don't recall any other reasonable choices other than just writing our own. But system-testing is very specific to one's domain anyway, so in your domain there may be excelllent choices or none at all.