Map what is actually there
Code, infrastructure, deployments, data, integrations, access, and the manual steps that hold it together.
guest@make-directory:~$ cat ./solutions/stabilize-modernize.md
make-directory:~/solutions/stabilize-modernize
Make the system dependable before you build anything else on it.
Unreliable, undocumented, or inherited technology, made dependable, maintainable, and safe to change. We take on applications, infrastructure, and AI-built prototypes that nobody currently owns.
guest@make-directory:~$ cat ./sound-familiar.md
the situation
Something important works, mostly. But the person who built it is gone, nobody is sure how it deploys, and every change carries a risk that is hard to size. The safest-feeling option is to touch it as little as possible, which is how it gets worse.
The original developer or agency is no longer involved
Deployments are manual, undocumented, or done by one person
Nobody can say confidently what would happen in an outage
A prototype got into production and never got production engineering
Security updates keep being deferred because nothing is safe to touch
Every estimate comes back padded, because the system is unknown
guest@make-directory:~$ cat ./what-changes.md
the outcome
A system your team can change without holding their breath.
- What exists is documented, including the parts that only lived in someone’s head
- Deployments are repeatable and reversible
- The risks are known, ranked, and either fixed or consciously accepted
- Access, backups, and recovery are verified rather than assumed
- The next change can be estimated honestly
guest@make-directory:~$ cat ./how-we-approach-it.md
how we approach it
What the work actually looks like.
Rank the risk
Not everything needs fixing. We separate what could take the business down from what is merely untidy.
Stabilize first
Backups, deployments, monitoring, and the security basics — the things that make everything after it safe.
Modernize deliberately
Replace, refactor, or leave alone, in an order that keeps the business running throughout.
guest@make-directory:~$ ls ./what-it-might-be
what this could become
What it turns out to be depends on what we find.
Here is what this work has become for other people, so you can get a feel for the range. Which one fits your situation is something we work out together, once we understand it.
- A documented deployment pipeline where there was a manual process
- A refactor of the parts that change most often, and none of the rest
- A migration off infrastructure nobody understands
- Production engineering for something AI or a contractor built quickly
- A rebuild, but only where the evidence supports it
- Sometimes: leaving it alone and writing down why
guest@make-directory:~$ cat ./proof.md
work we can show you
A modernization toolchain, in public
We build and maintain an open-source COBOL toolchain — dependency and call-graph analysis, a transpiler verified by differential testing, and a REST bridge that keeps compiled business logic reachable during a migration. It is the same method applied to the hardest version of this problem.
Take a lookguest@make-directory:~$ cat ./where-this-goes.md
where it usually goes
Usually Essential or Growth or Partner.
This work usually opens with an assessment, so the plan is built on what is actually there rather than a guess. From there most engagements settle into Growth, or Partner when nobody internal is owning the technical decisions.
guest@make-directory:~$ open ./software-ownership-checklist
no commitment
Not ready to talk? Find out who actually owns your software.
A printable 42-point review of access, documentation, hosting, backups, security, deployments, integrations, and long-term responsibility. Work through it on your own time — the questions you cannot answer are the useful part.
guest@make-directory:~$ ls ./related-reading
related reading
How we think about this.
Why Your Website Keeps Breaking (And What You Can Do About It Without Hiring a Full Dev Team)
A practical guide for growing businesses to understand the value of on-call development support without the cost of a full-time hire.
Signs Your Business Has Outgrown Its Website PlatformHow to recognize when your current website platform is limiting updates, integrations, performance, SEO, or internal workflows.
Why Discovery Matters Before a Software ProjectDiscovery helps teams understand scope, risk, users, systems, and priorities before committing to a larger software build.
guest@make-directory:~$ cat ./faq.md
questions
Frequently asked questions
Can you work on a system you did not build?
That is most of what we do. Inherited applications, contractor handoffs, and systems whose original team is long gone are the normal starting point, not an exception.
Do we have to rebuild it?
Usually not, and we will tell you when the answer is no. Rebuilds are expensive and risky, and a lot of what looks like a rebuild candidate is actually an undocumented deployment process and three unpatched dependencies.
What if the code is genuinely bad?
Then you will hear that plainly, with the reasoning and the options. Bad code that runs the business still runs the business, so the question is never "is this good" but "what is the safest path from here".
We built it with AI and it works. Is that a problem?
Not inherently. It becomes a problem when something goes wrong and nobody can reason about the code, or when the next feature needs foundations that were never laid. That is a normal engagement for us.
guest@make-directory:~$ mkdir ./what-needs-to-change
next step
Tell us what is not working.
A few sentences about your situation is plenty to start with. We will come back with what we think it takes, and say so if we are the wrong people for it.
Not sure this is the right one?
These four overlap, and most real situations are a mix of them. An assessment sorts out which parts matter and in what order, and you keep the write-up either way.
Start an Assessment