Adelaide · South Australia
Design to the requirement.Then implement what fits.
Software engineer and technical leader. Custom systems, the design of those systems, and an implementation that follows that design. Fourteen years building software, five of them leading engineers. A stack is a means. The constraint decides.
- Learn
- Build
- Enhance
- Implement
Six parts of taking a requirement through to a system.
Select one. The note is how that part shows up when the system has to fit a specific constraint, not a skill score.
The shape comes from the requirement: who decides, which part may act, and what has to stay visible afterward. A runtime is chosen after that drawing, including a local model when the data has to stay on hardware I control.
Chosen because the requirement asked.
Fourteen years building. Five of those leading. The spans sit under the work. They are not the pitch.
Design
The requirement is the first artefact.
I write the constraint before I pick a framework. If it belongs to someone else, their constraint outranks a tool I already like. The design is what can be disagreed with. The implementation is what follows once that disagreement is settled.
Learn the constraint. Build the system. Enhance what holds. Implement what fits.
Three systems designed to a specific constraint, then implemented. The same sequence is how I take a requirement that is not my own.
What I check before the design is settled.
The requirement comes first.
I write the constraint before I pick a runtime. When the system is someone else’s, their constraint outranks a tool I already like.
Build before assuming.
If I can test the design against the requirement directly, I would rather test it than extend the argument.
Understand the trade-off.
There is rarely one architecture that is correct for every constraint. I write down what this implementation gives up.
Local when control is the requirement.
Ollama, LM Studio, Open WebUI, and NVIDIA NIM are runtimes I design and deploy when the data has to stay put. They are not the default answer to every brief.
Open where the mechanism matters.
If the people living with the system need to see what it is doing, I prefer software I can read. GitLab CE and OpenCode sit in that preference.
Privacy is part of the design.
If the requirement is that data stays with the system, that is drawn in at the start. Privacy added after the path is chosen is a patch.
Automate the repeated part.
If a person has to repeat the same intervention, the process is what gets redesigned. On the homelab, local models do that operational work.
Keep the system understandable.
Complexity has to earn its place in this requirement. A narrow agent with a trace is easier to account for than a roaming one.
Designed in order to learn the design.
These exist because I wanted the architecture in my hands. The method is the same one I use when the requirement comes from someone else.
Iterating
Governed agents
Active
Multi-agent DevOps
Active
Homelab
How the practice moved
Requirements still being designed against.
Attention, not a claim of mastery.
- Agentic architectures
- Local AI as a runtime
- LLM orchestration
- AI-assisted engineering
- Developer tooling
- Self-hosted infrastructure
- Privacy-preserving systems
- Automation
Contact
If you have a requirement, write. Email is the direct path. LinkedIn works as well.