Get the architecture right before the first line of code locks you in
Technical architecture and system design is the up-front engineering that decides how a complex system is decomposed — what the major pieces are, what each is responsible for, how they communicate, and which technologies they are built on. It removes the most expensive class of mistake: structural decisions made implicitly, discovered two years later as the reason every change takes a quarter and nothing can be tested in isolation.
Willowark grounds architecture in the constraints that actually bind: throughput and latency numbers, failure modes and their costs, the team that will maintain the system, and where requirements are most likely to change. We hold opinions loosely and quantify where possible — a day of benchmarking a candidate database or bus load beats a week of whiteboard debate.
R&D & PrototypingHow the work gets done
The same way every time: scope, build, hand over.
The work produces decisions, written down. We define component boundaries and the contracts between them — APIs, message schemas, timing budgets — because well-drawn boundaries are what let teams work in parallel and let pieces be replaced later. Technology selection is done against explicit criteria with the rejected options and reasons recorded, so future engineers inherit the why, not just the what. For systems spanning hardware and software, the design allocates requirements across layers: what the controller guarantees, what the edge service guarantees, what the cloud is allowed to assume. High-risk elements get prototyped during design, not after commitment.
The deliverable is documentation a team can build from and a reviewer can challenge: architecture views, interface definitions, a decision log with rationale, and a risk register with mitigations. Success shows up later, in the boring way — features landing without cross-cutting rewrites, subsystems tested independently, and new engineers becoming productive from the documents rather than from archaeology.
An architecture engagement starts by extracting the constraints nobody has written down: the peak load in numbers rather than adjectives, the failure that would actually hurt, the parts of the system most likely to change, and the skills of the team that will own it. Those constraints become the criteria the design is judged against. Where a load-bearing choice depends on something uncertain — whether a message bus sustains the rate, whether a controller meets the timing budget — we build a narrow prototype and measure, because a design that rests on a hopeful benchmark from a vendor page is not a design yet.
The output is meant to be argued with. Architecture documents are delivered in editable, version-controlled form, with the decision log and rejected alternatives included, so your team can revisit a choice when its assumptions change instead of treating the design as scripture. When a proposed approach turns out not to work — a prototype misses the throughput target, a compliance constraint rules out a technology — the report says so plainly and offers the fallback, because that finding is the reason the design phase existed. Everything produced is yours, and the build phase can be run by us, by your team, or by anyone you choose.
Scope it in writing
What we agree before work starts
- System architecture document with component responsibilities and boundaries
- Interface definitions: APIs, message schemas, and timing budgets
Build with checkpoints
Working results, not slide decks
- Technology selection with evaluated alternatives and recorded rationale
- Risk register with prototyping results for high-uncertainty elements
Hand over something you own
Documentation, source, and training
- Build-phase plan sequencing the work to retire risk early
- Prototype source and benchmark results for the design's load-bearing decisions
Sound familiar?
Where technical architecture & system design earns its keep.
A funded product where the next hire depends on knowing what is actually being built
A system rewrite where the team knows the current structure is wrong but not what right looks like
A hardware-plus-cloud product needing responsibilities allocated across firmware, edge, and backend
An architecture review before a major investment, by engineers with no stake in the original design
Ask about Technical Architecture & System Design
Describe the problem. Get a straight answer.
One line is enough. An engineer replies within a business day.
Related work
X-ray thickness gauge
Components:
- X-ray source (+ detector): Source and detector pair measuring attenuation through the material.
- Acquisition (signal chain): Signal conditioning and acquisition.
- Gauge software (thickness model): Calibrated model converting attenuation to thickness.
- Line control (feedback): The line's controller, closing the loop on thickness.
Connections:
- X-ray source to Acquisition
- Acquisition to Gauge software (calibrated)
- Gauge software to Line control (thickness)
An industrial measurement company · Industrial measurement
X-ray thickness gauge
A complete X-ray based thickness gauge: equipment assessment, hardware selection, electrical and hardware engineering, API integration, all software, and commissioning — delivered as a working instrument.
Read the case study →Common questions
Asked before every technical architecture & system design project.
Is a big design phase compatible with working iteratively?
Yes — the failure mode to avoid is designing details that should emerge from iteration, not skipping structure. We design the load-bearing decisions deeply (boundaries, contracts, data flow, technology bets) and leave the rest deliberately open. Good architecture is what makes iteration safe, because changes stay local to a component.
Can you review an architecture our team already designed?
Yes, and it is some of the highest-value work we do. An independent review before major investment examines the design against your actual constraints — load numbers, failure costs, team skills — and returns specific findings with severity, not vague endorsements. Sometimes the answer is that the design is sound, which is also worth knowing.
How long does an architecture engagement take?
Reviews typically run one to three weeks. Ground-up design for a significant system usually runs four to eight, including targeted prototypes of the riskiest elements. The scale to judge it against is the build it precedes: a few weeks of design against a multi-quarter build is the cheapest insurance in the project.
Does the architecture lock us into specific vendors or technologies?
It should not, beyond the few choices that are genuinely load-bearing. Good boundaries are what let you swap a database, a cloud provider, or a controller family later without touching everything else, and we design the contracts between components with that in mind. Where a technology choice does carry real lock-in — some managed services, some silicon — the decision log records it explicitly, with what leaving would cost, so it is a decision you made rather than one you inherited.
Our team is small. Will we get a design we can actually build and maintain?
That is one of the constraints we design to, and it changes the answer. A three-person team should not be handed a twelve-service architecture, however elegant. We weigh operational complexity — how many things need deploying, monitoring, and understanding at three in the morning — as heavily as technical fit, and we prefer a simpler design with a documented path to scale over a sophisticated one nobody on staff can debug.
Where this sits
Technical Architecture & System Design, inside a r&d & prototyping system.
The lit component is the part of the system this service delivers; the rest is what it has to work with.
Hover or focus a component to see what it is and what it talks to. Arrow keys move between them.
Requirements become a bench prototype with real sensors and firmware; a test rig produces data; a pilot unit runs in the field; and the design is handed to production with everything documented.
Components:
- Requirements: What it must measure, survive and cost.
- Bench prototype (MCU + sensors): Dev board, real sensors, real signal chain.
- Firmware: Acquisition, processing, comms, update path.
- Test rig (data): Instrumented tests against known references.
- Pilot unit (in the field): A handful of units where the product will live.
- Production (handoff): Drawings, BOM, test procedure, firmware — yours.
Connections:
- Requirements to Bench prototype over handoff
- Bench prototype to Firmware
- Firmware to Test rig over serial
- Test rig to Pilot unit over handoff
- Pilot unit to Production over handoff
Strategy. Software. Systems.
Have a system that should exist?
Tell us what your operation is doing manually, what isn't connected, or what you're trying to build. We'll tell you plainly whether and how we can help.