Atypical Resolvers Discuss the situation
00

Special situations engineering

When a software project is always nearly done breaking in new places down to one person built by AI nobody read about to meet real users I'm who you call.

The date has usually moved twice by the time I hear about it, and nobody can say which thing is actually holding it up. I find that out. Then I stay and fix it.

I'm Adam Dyer. Twenty years in software, mostly enterprise, mostly systems that had already gone wrong once.

Discuss the situation See the situations
Schedule comparison Two schedules against the same time axis and the same committed date. In the typical one, infrastructure, software, and security run strictly one after another with a marked handover gap between each, security arrives last as a short block, and the release milestone lands well past the committed date, marked late. In the second, each phase takes exactly as long, software starts the moment infrastructure finishes because there is no handover to wait on, security runs the length of the engagement rather than arriving at the end, and the release milestone lands before the committed date. Committed date Late Typical Infrastructure Software Security Atypical Resolvers Infrastructure Software Security
The same work, scheduled twice. Every phase is the same length in both rows, so all that changes is the waiting. The top schedule stops at each handover and saves security for the end, and the release slips. In the bottom one the three lanes have a single owner, so nothing queues at a boundary and security runs the length of the work.

Project recoveryProduction readinessSecure systemsTechnical leadership

01

Situations

These are the situations I am called into.

If one of them describes your project, the first conversation will be short and specific.

  • 01 The prototype works, but it cannot safely go live. It was built to prove the idea, and it did. Now it has to survive real users, and nobody on the team wants to be the one who says it's ready.
  • 02 The project has stalled and nobody can say exactly why. Everyone is busy and the status is green. The date has moved three times. Nobody is slacking, which is the hard part to explain upward.
  • 03 You inherited a system that is fragile, undocumented, or insecure. The people who built it are gone. The documentation is a wiki page last edited two years ago. Every change turns up something else that was quietly depending on it.
  • 04 The architecture no longer fits the product. Every new requirement costs more than the last one. Your engineers know exactly why, and they have told you, and it never quite becomes the priority.
  • 05 Releases depend on one person remembering the steps. Deployment happens when that person is free. Nobody has tried the rollback.
  • 06 You need senior technical direction without a full-time hire. Somebody has to own the architecture and answer for it. Hiring that person takes six months, and you would be interviewing for it yourself.
  • 07 An AI feature needs real boundaries before customers touch it. You need to be able to say what the model can reach, what it can spend, and what you could reconstruct afterward if it went wrong. Right now the platform defaults are answering those for you.
  • 08 A lot of the code was written by AI, and nobody has read it closely. It works in the demo and the tests pass. The same tool wrote the tests, so nobody is quite sure what they prove.
02

Capabilities

Most engagements touch more than one of these.

Which ones is not usually clear at the start.

Project recovery

  • Codebase and infrastructure assessment
  • Failure-point and root-cause analysis
  • Sequenced recovery plan
  • Hands-on remediation

Production readiness

  • SaaS and backend architecture
  • Authentication and authorization
  • API design and integration
  • PostgreSQL data architecture
  • Docker and cloud deployment
  • CI/CD and operational hardening

Secure systems

  • Application security
  • Identity and access design
  • Agent permissions, spend limits, and audit trails
  • Threat-informed architecture
  • Security requirements
  • Production acceptance review

Technical leadership

  • Fractional CTO support
  • Architecture ownership
  • Code and design review
  • Coordination across developers, vendors, and stakeholders
03

Approach

Four stages. Most of the work is in the fourth.

The written assessment ends at stage three. A lot of engagements stop there.

  1. 1

    Understand the system

    Read the code and the deployment until the system's real behavior is clear. Some of what people tell you will be out of date, and they will not know it.

  2. 2

    Find the constraint

    Find the thing that is actually holding the project. Sometimes it is the architecture. Sometimes it is one person's calendar.

  3. 3

    Set the recovery path

    Write down the shortest credible route to a system you can put in production. The part people argue with is what gets left out.

  4. 4

    Resolve the problem

    I write the code myself, starting with whatever stage two turned up. I stay until it holds.

04

Work

What the work looks like from the inside.

Twenty years of it sits under client confidentiality. This is one I can take apart in public, anonymized to the line the client agreed. No name, no product, nothing that identifies the specialty. The second is my own, and still in development.

A clinical decision-support tool, from prototype to hosted product

Situation
A single-file HTML prototype. It demonstrated the workflow and the workflow was right. It had no authentication, nowhere to keep data, and no way to reach the model that did not involve shipping a key to the browser. The brief was to host it so clinicians could log in and use it.
Underneath
Hosting was the smaller half. A prototype can hold everything in one file because nothing in it has to survive a second user. With real clinicians and real clinical input, identity, persistence, server-side model access, and the retrieval path the product would want later stopped being separable questions. Deployment then turned up a second one. The serverless platform had an execution-time ceiling that the AI request path kept hitting.
Decision
I read the prototype as the specification for the workflow rather than as the architecture to keep. Authentication and persistence went to Supabase on PostgreSQL. The Anthropic calls moved server-side. The schema was laid out for the retrieval work the product would want later, so that adding it would not mean migrating everything again. On the ceiling, I moved the API execution layer to Cloudflare Workers. Engineering around it would have meant carrying that workaround into everything built afterward.
Result
A hosted application clinicians log into, with the model API out of the browser and a data model the next piece of product work can build on. The job had been scoped as a deployment. What it turned up was an architecture problem and a platform problem sitting inside it, and both were cheaper to find then than after the first hundred users.

Making an agent prove it is allowed to act

Problem
An AI agent can be told what it is allowed to do. That instruction is not an authorization system. The service receiving its request has to decide independently whether that specific action is permitted.
Engineering choice
I'm building an identity and authorization system that starts with passkey sign-in and OpenID Connect, then uses signed mandates to establish what an agent can do and receipts to prove what it did. Separate verifier and enforcement components check the authorization and refuse actions that do not pass.
Status and related work
This is development work, not a customer deployment. The identity system itself is private. My public architecture note on agent approval boundaries discusses the related problem of enforceable controls versus controls an agent can work around.
05

About

Who does the work.

Atypical Resolvers is my practice. I'm a principal software engineer and secure systems architect.

Companies call me when the problem has stopped being one person's job. It crosses the architecture and the infrastructure and the security posture, and the team is good but nobody there owns all three at once.

The architecture decisions are mine. So are the security calls and the production sign-offs. I use AI-assisted engineering underneath that, heavily, for implementation and testing and analysis. Nothing it writes ships without a test that was written before it.

In a URL threat-evaluation service I built, deterministic checks decide the verdict and the model is handed the finished verdict to explain. If the model call fails, a stock message stands in for the explanation and the verdict is unchanged. The code is public.

I also teach the senior capstone in cyber operations at a university. I founded CyberWeb Services, a cybersecurity company. Atypical Resolvers is a different kind of work: hands-on software engineering, architecture, and technical leadership.

Building CyberWeb also meant building software for the business itself: customer and contract management, email-driven ticketing, alert integrations, and reporting.

There is no account manager and no handover to a junior team. If you want to hear about work closer to your own situation than anything on this page, ask on the first call and I will describe what I am allowed to.

06

Contact

Tell me what the project needs.

A short description is enough: what the system does, where it stands, and what a good outcome looks like.

I will tell you if it is not something I should take. That happens fairly often.

Write to

hello@atypicalresolvers.com

Send the details

No newsletter, no sequence, no CRM drip. One reply from one engineer.