There are things that could (should?) be done from the start. Most has to do with automation. For example automated build tools. Maybe you don't want automated unit tests in the beginning but those parts can be added later without changing the company's culture and stucture too much.
Or automated invoices. It is much easier to change this than changing a co-worker who manually created all the invoices.
Don't ever put anything into production that's not automated. Ever. "Oh it's a simple HTTP server that's going to be used by 5 people". Cool. Automate it. "Oh but it's going to take time!". I thought you said it was simple...
When things are not automated, we treat them differently. If a server is not automated, now it becomes time-consuming to setup another, which means it's now a pet, not cattle. But if it is automated and is misbehaving, we can easily replace it (and save the current for troubleshooting later if necessary). Or we can spin up 100 of them.
Same goes for development. If builds are not automated, they become more difficult to do, more error prone, which means people will avoid making contributions unless they are forced to do so (by some ticket). When contributing to a code base that has no guardrails becomes a lose/neutral proposition, people won't want to.
And now it's been 5 years and it's difficult to automate things because there's a 100 different workflows that people use and you are going to break them.
Yes, yes, yes. Just CI/CD alone has been a huge productivity boost for one of the teams I lead. The thing is, as you scale (50 people to 200+), people adapt to depend on processes rather than individuals.
If the process is automated and well documented, you'll be have even more power to tweak the inner workings without retraining anyone.
Like someone else said, even if it doesn't save you time, adding automation simplifies your processes and creates a powerful abstraction, which will come in handy when you do start hitting scaling challenges.
Other examples: linting code, configuration, documentation, etc.
Or updating a registry, release version somewhere, even sending an email/message to someone when something happens (a new client signs up, emails with a certain keywords).
So many processes beyond development can be automated. SalesOps is very simply doing that for Sales teams (managing sales pipelines, distributing leads, generating reports). Marketing Automation has become its own field (targetted drip campaigns, now add another layer: account based targeting based on rules).
Not OP, but I think s/he means automating the processes of provisioning servers (settings, common software), and deploying changes to your infra/code/apps.
Interested why you'd say this, can you elaborate? Do you mean tests in general or unit tests specifically?
I can't imagine automating a CD pipeline without having some automated testing as an integral step. If you don't have automated tests, how do you remain confident that you haven't introduced bugs/regressions?
Even in a small codebase that's easy to do - especially when you're evolving quickly.
Like I say: not tacit criticism, genuinely interested.
I think the key point in the OP’s statement is “early on”
I think unit tests (or just more generally a test suite) is invaluable. But when you’re starting out small (1-3 person dev team) and the API is changing so rapidly (we learned something this week we didn’t know last week so that new service now only does 1 thing instead of 5 things), tests can _really_ slow down development. And as mentioned by the OP as well, adding unit tests (or a test suite in general) shouldn’t be too hard once you get a stable API
I might be preaching to the choir so to speak, but that’s just my $0.02
As someone who has mostly written early stage software with 1 to 3 developers, the single most reason to skip tests is the rapidly changing APIs. Also it is ok to ship somewhat buggy code. Use case validation and speed trumps accuracy.
Also invariably a lot of early stage code is in the front end and FE testing is very time consuming.
What has been immensely helpful is an automated build and deploy system, which quite honestly is very expensive to build in the iOS world. I just want a one click deploy to a clean machine every time I decide to deploy. This is kinda trivial in the backend world using containers but not so in the iOS world.
Appreciate the responses. Most of the things I work on involve financial modelling, so tests are as much part of specification as they are validation. I can see them causing some drag for evolving less algorithmic code, particularly UI. Always interesting to get different perspectives - thanks.
Or automated invoices. It is much easier to change this than changing a co-worker who manually created all the invoices.