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 a principal software engineer and a secure systems architect. Twenty years, 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.
02

Capabilities

Four areas of work. One person accountable for all of them.

Most engagements touch more than one of these. Which ones is not usually clear at the start.

Project recovery

Establish what is actually wrong, then get the project moving again.

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

Production readiness

Turn a system that demos well into one that can be operated and trusted.

  • 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

Design for the conditions the system will actually meet.

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

Technical leadership

Hold the technical direction while the team builds.

  • 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. Most of what I get hired for is stage four.

  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. I fix the architecture, I harden the deployment, and 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.

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.
05

About

Who does the work.

I'm Adam Dyer. Principal software engineer and secure systems architect, twenty years of it, nearly all enterprise. Atypical Resolvers is my practice.

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. If one of those decisions turns out wrong, that is mine too.

There is no account manager and no handover to a junior team. You email me and I answer.

Client work is confidential, so the engagement above carries no client name and nothing that identifies them. Ask on the first call and I will talk through the closest thing I am allowed to describe.

06

Contact

Tell me where the project is stuck.

A short description is enough: what the system does, where it is stuck, 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.