a build system
Imagine baking a cake from a long recipe: melt the butter, mix the flour, bake for 40 minutes, then ice it. If you did this by reading each step aloud and doing it by hand every time, you would make mistakes, forget a step, or do them out of order. A build system is the kitchen assistant that knows the whole recipe for turning your source code into a finished, runnable program, and carries it out the same way every single time.
Concretely, building a real program is rarely one command. You might have to run the preprocessor and compiler on a dozen source files (gcc -c a.c, gcc -c b.c, ...), then link the resulting object files together, then maybe copy data files or generate some code first. A build system records all of these steps and the order they must happen in, so that instead of typing them by hand you run one command (often just make) and it does the right sequence for you. It can also do only the work that is actually needed, skipping anything already up to date.
Why it matters: a build system gives you automation (one command instead of twenty), reproducibility (the build runs the same on your machine, a teammate's machine, and a server), and speed (it rebuilds only what changed). Without one, a growing project quickly becomes impossible to build correctly by memory. The trade-off is that you must describe your build accurately; a build system faithfully automates whatever you tell it, including mistakes.
Without a build system you type, every time: gcc -c main.c -o main.o gcc -c util.c -o util.o gcc main.o util.o -o app With one you type just: $ make
A build system turns a fixed sequence of build commands into a single reproducible command.
A build system does not understand your code's meaning; it only knows which files depend on which and what commands to run. If you describe the dependencies wrongly, it will happily produce a broken or stale program.