WilhamBrodwolf
Systems that hold.
I build software that behaves at 3 a.m. exactly the way it did in the demo.When code becomes a commodity, engineering is what makes it work as it should.
I work where engineering, architecture and leadership overlap.
I lead the development of scalable and reliable systems — helping engineering teams break down complex problems while keeping a hard focus on business impact, operational efficiency and long-term maintainability.
Eight years across e-government, e-commerce, payments and insurance. Most of what I ship is the unglamorous kind: reconciliation that has to balance, SLAs that can't slip, pipelines nobody should have to think about.
* Yes, these are real. No, compliance won't let me show you the cool stuff. I asked.
Data2
API2
Tests2
Eval pass rate per iteration
62% this run
+35 ptssince the first draft
- Unit tests148/148
- Type check0 errors
- Eval suite97%
Agents write the code. Engineering decides what ships.
I use AI the way I use any production system: grounded in real context, checked by tests and evals, signed off by a human.
- 01
Grounded before it writes a line
The agent starts from the ticket, the decision records, the schema and the logs — not a blank prompt. Context is assembled, not improvised.
- 02
A plan you can review in a minute
Work is split into small changes by layer, so the diff is predictable before anything is generated.
- 03
Tests and evals decide, not vibes
Every iteration runs types, unit tests and an eval suite built from real cases. The pass rate has to climb before it earns a human's time.
- 04
Human sign-off before anything ships
A reviewer approves and merges. From there nothing goes out by hand: the merge itself starts the pipeline.
- 05
Every merge earns its way to production
Lint, unit and end-to-end tests run on every merge. Only a green pipeline ships a canary, and the same dashboards watch it. If a number moves, it rolls back on its own.
Manual work, rebuilt as workflows.
Most teams lose hours copying data between WhatsApp, spreadsheets, email and the CRM. I map the process, then rebuild it in n8n: an LLM where judgement is needed, plain rules where it isn't. Every run is logged, retried and easy to change.
One product, every screen.
You are in the session too: click the screen or change the theme, and the code follows.
One core. Every channel.
Your customer is at a desk, on a phone in the field, and inside someone else's system through an API. Same domain rules, same guarantees — a different surface. I build the core once: typed, tested, observable. Then every channel stays thin enough to change on a Friday afternoon.
Architecture that fits the problem
Not a monolith out of habit, not microservices out of fashion. The shape follows the domain and the team.
Reliability is a feature
SLAs, idempotency, replayable events and dashboards that answer the question before someone asks it.
Leave it documented
Decision records, runbooks and tests, so the team keeps moving after I step out of the room.
Start small. Scale when the numbers ask.
A system should be as complex as the problem it solves, and no more. I start with the smallest architecture that works, validate it with real users, and add pieces only when traffic, the team or the risk calls for them. You spend less up front, learn sooner, and skip the premature over-engineering nobody has time to maintain.
One server
Web app, API and database share a single server. It costs little, ships this week and is easy to change while the product finds its shape.
Next step when: CPU stays above 80% at peak hours
- Active users
- Peak load
- Monthly cost
- $$$$$$
- Moving parts
- 3
Not every system grows the same way. This is just one example of complexity added step by step.
The purpose of software engineering is to control complexity, not to create it.
If you haven't planned for failure, you've failed to plan.
Every system fails at some point: a region goes dark, a disk fills up, a deploy goes wrong. It is a matter of when, not if. So failover is planned from day one. Health checks, weighted routing and slow start are design decisions, and this drill runs long before production needs it.
What I reach for, and why.
The orbit rests while you aim. Filter by category or pick a logo to see where it fits.
Toolbox
29 tools, 22 in production
Pick a logo to see where I use it. Arrow keys step through them.
22 of 29 connected in totalPick a time.
Thirty minutes, no deck. Tell me what is breaking, or what you are about to build.
wilham@brodwolf.dev30 min.