The most common way a junior developer’s first real project goes wrong is not bad code. It is good code written against the wrong shape: a database that cannot hold the third requirement, an API that has to change the week before handover. The solution architecture package exists so that never happens on a Blacksmith.Works project.
Who writes it and when
A senior engineer, with at least five years of production work, writes it after the scoping call and before the first apprentice is matched. It is per-event work for the mentor, scoped and paid per project, and it ends with a hand-off: the architect is not on call for the build unless they also take the Mentor Lead role on it.
Every project size includes one. Starter, Professional and Enterprise all begin with the package; the difference is how much of it there is to write.
What is in it
- The problem, restated.The brief the company sent, rewritten as what the system has to do and for whom, with the questions the architect asked and the answers they got. If the brief said “inventory tracker”, this section says how many locations, who adjusts stock, and what happens when a count is wrong.
- The stack choice, with the reason.Not “we like this framework” but why this stack for this company: what they already run, who will maintain it after handover, what the apprentice slots can realistically cover.
- The module breakdown.The system drawn as boxes and arrows, each box small enough to be one apprentice’s responsibility. Data model, authentication and roles, integrations, background jobs, the admin surface.
- The slot plan. Which modules become which apprentice slots, in what order, with the dependencies between them. This is the part that turns architecture into a Jira board.
- The non-negotiables. What the reviews will enforce: where validation lives, how errors surface, what is logged, what is never logged, how secrets are handled. Written down so the apprentice is not guessing at the standard.
- The handover shape. What the company receives at the end: repository, deployment instructions, environment variables, the runbook for the one thing that will break at 2am.
What it turns into
The package becomes a Jira board: sprints, a backlog, tickets per module, and an account for each apprentice with the permissions to manage their own work. The apprentice does not start from a blank editor. They start from a ticket that says what to build, a diagram that says where it sits, and a standard that says what “done ” means. The senior who wrote it reviews the pull requests against it.
What it means for the company
You see the architecture before a line of code exists, and you can push back on it. It is the moment to say “we are moving off that CRM next year” or “the finance team must never see this table”. It is also your first piece of documentation: when the tool is handed over, the package is the map of it.
What it means for the apprentice
You get to work the way senior teams work, from day one. You read an architecture before you write code, you build inside constraints someone explained to you, and when you leave, you can explain in an interview why the system is shaped the way it is. That answer is one of the clearest signals of a junior who has done real work, and it is one most candidates cannot give.
Read how the whole engagement runs on the how it works page, or, if you are a senior engineer who writes these for a living, see what architecture work pays here.