Read ten CVs or three agency proposals and you'll see the same three words used almost interchangeably: developer, engineer, architect. Sometimes all three describe the same person, priced three different ways. It's tempting to shrug it off as vocabulary, but if you're the one hiring, budgeting or signing the proposal, the difference is real money in both directions. Pay architect rates for developer work and you're overpaying. Put developer judgment on architect decisions and you'll pay far more later, just less visibly.
So it's worth being precise. Not about the titles, which are genuinely muddled, but about the three kinds of work hiding behind them.
Why the titles got so muddled
Unlike civil engineering, software has no licensing body and no protected titles. Anyone can be a "senior architect" on the next business card, and title inflation is free, so it happens constantly. The same work is called "developer" at one company, "engineer" at another and "member of technical staff" at a third. Company size warps it further: at a five-person startup everyone does everything and titles are decoration, while at a bank the same words map to rigid pay grades and committees.
The upshot: a title tells you what someone was called, not what they can do. But underneath the noise there really are three distinct kinds of work, and telling them apart is worth your time.
The developer: makes the feature exist
The developer's unit of work is the task or the feature. Given a reasonably specified problem, a form to build, an endpoint to add, a bug to fix, they produce working code that solves it. Good developers are fast, precise and productive, and they're the engine of any software project, because most of shipping software is exactly this work.
None of this is a slight. "Developer" describes a scope, not a skill ceiling. The limitation isn't ability, it's ownership: a developer's job, as defined, ends when the feature works. The questions of whether it will still work under ten times the load, whether it opened a security hole, and whether the next person can maintain it belong to a different altitude.
The engineer: makes the system hold up
The engineer's unit of work is the system and its lifecycle. Engineering starts where "it works on my machine" ends: how does this behave when the network is slow, when the input is hostile, when the data is ten times bigger, when the person who wrote it has left? Engineers think in tests, failure modes, performance budgets, security boundaries and maintainability, and above all in tradeoffs, because engineering is fundamentally the discipline of choosing what to sacrifice under real constraints.
The practical difference shows up in ownership. An engineer owns the consequences of the code in production, not just its existence. When something breaks at 2am, the engineering mindset doesn't stop at patching the symptom; it asks why the system allowed that failure and what has to change so this class of problem doesn't come back.
The architect: makes the expensive decisions
The architect's unit of work is the decision that's expensive to change. Where do the boundaries between systems sit? Which service owns the customer data, and who has to ask it? Do we build this or buy it? Which database, which cloud, which of these two technologies do we bet three years on? Get these right and nobody notices; get them wrong and you're funding a rewrite in eighteen months.
Notice that the output here is mostly not code. It's decisions, constraints and the reasoning behind them, written down so a team can move fast inside safe walls. That's also where the role goes wrong: the architect who stopped coding years ago and now ships only diagrams drifts into an ivory tower, making confident decisions insulated from their consequences. The architects worth hiring still write code, not because the project needs their throughput, but because it keeps their judgment honest.
The same outage, three altitudes
Here's the cleanest way to see the difference. Say checkout starts timing out whenever the shipping-rates service gets slow.
The developer fixes the bug: finds the slow call, adds a retry and a sensible timeout, ships it. Checkout works again. The engineer asks why the system allowed the failure: adds a circuit breaker so a slow dependency degrades gracefully instead of hanging checkout, sets a latency budget, writes the test that would have caught it. The architect asks why checkout synchronously depends on shipping rates at all, and whether that boundary is in the right place, because if rates were cached and refreshed in the background, this whole class of outage disappears.
All three responses are correct. They're just operating at different altitudes, on different time horizons.
| Developer | Engineer | Architect | |
|---|---|---|---|
| Unit of work | A feature or task | A system and its lifecycle | Decisions spanning systems and years |
| Core question | "How do I build this?" | "How does this hold up?" | "What will we regret?" |
| Main output | Working code | Reliable, maintainable systems | Decisions and constraints |
| Time horizon | This sprint | This year | The next three years |
| Typical failure | Feature bugs | Outages and slow rot | Expensive rewrites |
The lines blur, and they should
If the table above reads like a career ladder, that's the wrong takeaway. These are hats, not castes. A good senior engineer does architecture every time they design a service boundary. A good architect writes code every week. A developer becomes an engineer precisely by being handed engineering concerns, the on-call shift, the performance budget, the postmortem, and taking them seriously.
On a small team, "architect" should be a hat someone senior wears a few hours a week, not a full-time role. The anti-pattern to avoid is architecture as a separate department: a person or committee that produces diagrams upstream of the people shipping, reviews nothing that comes back, and feels no consequences. Decisions made that way age badly, because the feedback loop that keeps judgment sharp has been cut.
Who you actually need, by stage
Pre-product-market fit. You need senior engineers who can wear the architect hat for an afternoon when a genuinely expensive decision shows up. A full-time architect is premature, the ground is shifting too fast for three-year decisions to mean much. But be careful at the other end too: a team of pure feature developers with nobody thinking about the system will build fast for six months and then hit a wall of their own making.
Scaling. This is when the expensive decisions arrive in bulk: the monolith groans, the second and third teams form, the data outgrows the database. Someone now needs to do deliberate architecture, even if it's still a part-time hat on your most senior engineer. Engineers own their systems end to end; developers give you feature throughput inside those walls.
Multiple teams, regulated industries, serious integration surface. Now dedicated architecture is real work: keeping ten teams' systems coherent, owning the compliance boundaries, deciding what's a shared platform and what isn't. This is the stage the title was invented for, and it's later than most org charts assume.
How to tell them apart in an interview
Titles are noise, so listen for altitude instead. Ask someone to walk you through a project they're proud of. A developer narrates features: what they built and what it did. An engineer narrates tradeoffs: what broke, what they measured, what they changed so it couldn't happen again. An architect narrates decisions: the options on the table, the one they picked, and what it cost or saved two years later.
Then ask what they'd do differently now. The developer answer improves the feature. The engineer answer improves the system. The architect answer questions a boundary. None of these answers is wrong, but they tell you exactly what altitude of judgment you're buying, far more reliably than the word on the CV does.
The bottom line
Developer, engineer and architect aren't ranks, they're altitudes: the feature, the system, and the decisions too expensive to change. Every real project needs all three kinds of thinking, and almost no project needs them as three separate salaried humans, what matters is that each altitude is genuinely covered by someone with the judgment for it. So ignore the titles, watch the questions people ask, and staff for the decisions your stage of growth is actually facing. That's the whole trick.