A software engineer designs, builds, tests and maintains software — not just writing code, but deciding how a system should be structured so it can be changed safely later. In a custom-software project most of the value sits in that judgement: what to build, what to buy, and what to leave out.
A software engineer designs, builds, tests and maintains software. The visible part is writing code; the valuable part is deciding how a system should be structured so it can be changed safely a year from now, by someone who was not in the original conversation.
On a custom project most of the money is decided before much code exists. What to build, what to buy, what to leave out, and where to put the boundary between systems — those four choices set the budget more than typing speed ever will.
Less coding than people expect. A working day typically holds some implementation, a good deal of reading existing code to understand what a change will break, reviewing colleagues' work, and conversations to pin down what is actually being asked for. The last one is where projects are saved or lost: a requirement that sounds obvious in a meeting is usually three different requirements once someone tries to build it.
Frontend (what the user sees), backend (data, logic, integrations), full-stack (both, to a working standard), and platform or DevOps (the infrastructure it all runs on). Alongside these sit data and ML engineering. For an SME buying custom software the label matters less than whether the engineer has shipped and then maintained something comparable — building is the easy half.
Employed, it is a salaried role with the usual Dutch employer costs on top. Bought as project work, agencies bill by the hour or by fixed price, and the difference matters more than the rate: hourly leaves the budget open-ended on your side, fixed price puts the estimating risk on the supplier. We set our figures out on custom software development and explain the trade in fixed price vs hourly.
Yes, and the ratio of judgement to typing has moved further towards judgement. Models write competent code quickly, which makes it cheaper to produce a large system nobody understands. The scarce skills are now specification, review and architecture — knowing what to ask for, spotting what is subtly wrong, and keeping the whole thing coherent. Generated code you cannot review is a liability wearing a deliverable's clothes.
In Dutch job adverts the two are used interchangeably, and treating them as a hierarchy is mostly marketing.
Depends on whether the software is your product or your tooling.
Ask about maintenance, not features. Anyone can demo something new.
Want this applied in your business? See how we take it to production:
We build this AI in production — at fixed prices, with one named expert. Start with a free consultation.
Book a free consultation →