Building got fast. Engineering didn’t.
Engineering Bay exists to close that gap: to supply the engineering that production demands and prototypes never needed, without slowing anyone down to do it.
Why we exist
In two years, the cost of producing working software collapsed. The cost of producing reliable software did not move much at all.
That gap is where businesses now get hurt. A founder ships something useful in a fortnight, gets customers, and inherits a system that has never been audited or tested and has no recovery plan. The product is validated. The engineering is unknown.
Traditional consultancies answer that with a rewrite, because a rewrite is easier to scope and easier to bill. We think that’s usually the wrong answer - it discards working software and the domain knowledge baked into it, and replaces a known set of problems with an unknown one.
Show the evidence
Every finding comes with what we saw and why it matters. If we can’t evidence it, we don’t claim it.
Rank by severity
A long list of style complaints is noise. We rank findings by what would hurt you in production.
Repair before replacing
Rewrites are a last resort, and they always cost more than expected. We keep what’s sound.
No alarmism
Security theatre helps nobody. We won’t inflate a risk to sell a remediation.
We’re not anti-AI. We’re pro-production.
We use AI-assisted development ourselves. It’s the biggest change in how software gets made in a long time, and telling people to stop would be pointless.
What changes with AI-built software
Code arrives faster than anyone’s understanding of it. Patterns are inconsistent because different sessions made different choices. Deliberate decisions get reverted by an agent that never knew why they existed. And the gap between working in a demo and holding up under ordinary use is wider than it looks.
What doesn’t change
Production has the same requirements it always had: data integrity, enforced access control, visible failures, and a backup that has been restored at least once. None of that got easier. It did get easier to skip.
Jason Baldwin
Engineering Bay is me. The person who inspects your system is the person who writes the report and walks you through it - there is no delivery team to hand you off to.
Twelve years building and operating backend and distributed systems. For the last six I’ve been CTO and founding engineer at a Series A proptech company: I wrote the first commit and still ship production code daily. That platform is a multi-region geospatial pipeline on AWS holding roughly 875 TB across some 800 million objects, plus the multi-tenant SaaS and public API on top of it.
Before that, a US esports platform that went from eight states to all fifty while its engineering team went from fourteen to forty - including migrating a live custom WebSockets protocol to GraphQL, and a codebase from JavaScript to TypeScript, without stopping the product. Before that, the backend for a European IoT platform managing over a million connected street lights. Go, TypeScript, Python, C#, PostgreSQL, Terraform. BSc Computer Science, University of Pretoria.
I’ve inherited a lot of systems that were built fast by people who were right to build them fast. The question that mattered was never whether the code was elegant. It was whether it would hold up under load, and during an incident at three in the morning. That is what an inspection checks.
- Read-only access by default
- Findings shared as we go, not held to the end
- Remediation in reviewable increments
- Your team keeps shipping throughout
- Everything documented and handed over
- No lock-in - the report is yours regardless
Why “Engineering Bay”?
Because it describes exactly what happens here.
A bay is where something is brought in, put on stands, inspected, repaired, tested, and signed off before it goes back into service. Software comes in, gets examined, gets the work it needs, and leaves with a clearance.
Bring your code into the bay.
A clear account of what you have, and what it needs before launch.