Independent architectural oversight
The builder builds. Oversight makes sure it's still standing in twenty years — things nobody sees today: the foundation, the load-bearing structure, the walls. In your software, that's the data model, the contracts, and the architecture. I draw on 30 years of experience building robust architectures — from proprietary languages and virtual machines to systems still running in production today.
Problem
The number of features, the number of screens, how fast the demo runs — those are the house's windows. Anyone can count them, so that's what decisions get made on. But a building's lifespan isn't decided by the windows, it's decided by the load-bearing structure: the data model, module boundaries, invariants, contracts between layers. A layperson can't assess that — and a vendor won't volunteer to show it.
The worst part is the delay: a house with bad structural design stands there with beautiful windows — for years. The flaw only shows up under a load nobody saw coming when the contract was signed. By the time the wall cracks, the original vendor is long gone from the project, and every change costs multiples of what it should.
Oversight isn't paid for by the vendor. It's paid for by the client — as insurance against the vendor.
What does it cost me if I skip oversight?
Nothing — until the flawed architectural decision shows up. Then it arrives all at once, usually at the worst possible moment, and fixing it under pressure always costs more than oversight during construction would have. The cost of oversight is an order of magnitude below the cost of the extra month of work an undetected risk forces on you.
The analogy that carries the whole service
One important boundary: I'm not a project manager. I don't track the schedule, invoicing, or compliance with a tender's requirements — that's what project managers and process oversight are for. I watch the structural side: the data model, module boundaries, contracts, and the decisions that decide whether, ten years from now, anyone can still safely change the system. A project can finish on time and on budget — and still be standing on sand. That's my turf.
Two services, two moments
One-off · before the decision
What lands in your inbox: a concise written assessment (typically 5–10 pages, not a hundred-page PDF) — a risk matrix of "what's on fire now and what can wait," an assessment of the degree of vendor lock-in, and specific recommended steps your vendor can act on right away.
A fixed price for the assessment, or a day rate. A written deliverable I put my name to.
Ongoing · during development
What lands in your inbox: notes with findings and recommendations after every review session; the ongoing architecture journal belongs to the client — it stays with you even after the engagement ends.
A monthly retainer with guaranteed capacity. I don't build — I watch. So I'm never competing with your vendor.
Indicative pricing
The prices below are a floor, not a ceiling — a specific proposal always depends on the system's scope. But you should know the ballpark before you write the first email. For comparison: construction-site oversight for a house typically costs 1.5–3% of the build's price. IT oversight runs similarly — a low single-digit percentage of the system's value, for oversight of an investment in the millions.
A second opinion on a vendor proposal
fixed price · an assessment of scope, price and risks
Architecture assessment before building
a risk matrix + recommended steps · a fraction of the cost of one person-month of development
Audit of an existing system
a basis for the extend-vs-rewrite decision · depends on scope
Day rate outside the packages
per day · consulting, workshops, attending vendor negotiations
Basic
1 review session a month · a written note · maintaining the architecture journal. For calm phases and smaller projects.
Standard
2 review sessions a month · ongoing availability for questions in between. The most common choice.
Intensive
weekly review sessions. For the design phase — that's when things get set in concrete — and crisis periods.
Relationship with your vendor
A good contractor isn't afraid of construction oversight — it covers them. A decision logged in the journal protects both sides: the client from spaghetti code, the vendor from a later "you should have known that." I'm not an approval gate that slows down the sprint; I'm a partner for discussing the boundaries, showing up on the agreed cadence of review sessions.
I say "this is a risk", the tech lead says "that's a standard pattern" — and both get logged in the journal with both sides' arguments. The decision always sits with the client; oversight has no right of veto, only a duty to warn. Two years later, nobody has to argue about who knew what — it's on record.
Oversight doesn't get involved in day-to-day work or code review. It only deals with the load-bearing walls — the data model, module boundaries, key contracts — at pre-agreed checkpoints. An hour spent discussing a design today is cheaper than a month of rewriting two years from now.
Free download
You don't need to understand the technology to tell how your system is really doing. You just need to ask the right questions and listen carefully. I've put together five questions — from bus factor to vendor lock-in to system longevity — and for each one, a guide to what a good answer looks like and what counts as a warning sign.
Four pages, no jargon. Written for directors, secretaries and managers who are responsible for an information system without being IT people themselves.
No registration, no email. Just read it. (Currently available in Czech only.)
When to call me
Why me
I've been building robust architectures for 30 years — and I know why some stand for decades while others fall apart at the first change. Oversight isn't decided by a list of frameworks, but by structures that hold up. My track record isn't measured in star ratings, but in years of continuous operation. And because architecture withers without practice, I keep actively designing — currently including a multi-LLM document-processing pipeline and models ready for AI agents as first-class consumers of a system.
years in production
The d.process low-code platform — deployed in 2010, still running in public administration today
years, one piece of software
Software from the 90s that's still printing in live production today — because it had an architecture
years of experience
From 1990, through proprietary languages and virtual machines, to AI pipelines · Ing., ČVUT FEL
"Everything must have an architecture." A bad system can be predicted before it's even built — from the conditions it's built under. My job is to change those conditions in time: invariants enforced by the design, knowledge written down once, decisions kept in a journal. That's the whole difference between a system that gets maintained and one that gets worked around.
Bonus for companies with 25+ employees
I am a registered provider of alternative performance under § 81 of Act No. 435/2004 Coll. The same money you'd otherwise pay the state with nothing in return can fund independent oversight of your software.
How alternative performance works →A cliché-free summary
The first review session is free of charge and takes place online: we'll go through your project or system, and I'll tell you straight where the load-bearing wall is and where it's just plaster.
Book a review session →Jakub Lebeda · Company ID (IČO) 19074671 · +420 607 720 317