This piece is about how the previous developer had built it, why each control was inert, how we fixed it, and the practices we kept afterwards. The details of the product are not the point; the pattern is, because it is the shape of most inherited systems we see.
The platform has a public signup form. As built, submitting it created a durable account, a profile, and an email on the first request, before the address was verified. Bots found the form. Each hit left a real record in the database and sent real mail to an address the bot had chosen.
For the organization that owns the platform, this was not a data-hygiene problem. A trusted institution sending unsolicited email to harvested addresses is a reputation and data-protection problem. That framing decided the priority.
Six separate things were true at once. Each looked fine on its own, and all of them had passed review before we arrived.
The CAPTCHA was pointed at the wrong subdomain. A bot challenge was integrated into the form and its keys were present in the configuration. They had been issued for a different hostname from the one the form was served on, so the challenge never verified anything on the live site. This was the single largest failure: one configuration value, never checked against production, removed the outermost defence entirely.
Account creation preceded verification. The form wrote permanent state first and asked for proof of ownership second. Anything that reaches the form can therefore create records.
The rate limits were real and did nothing. The application used a cache-backed rate limiter. In the environment where the limits were tested, the cache store was a null store, so every limit silently allowed everything. Code review saw four rate-limit calls and moved on. No test ever exercised them.
Behind a proxy, per-IP limits collapsed into one bucket. The application sat behind an edge network and a platform router with no trusted-proxy configuration. Every request resolved to the same upstream address, so a per-IP limit became a single global limit. IP is also the wrong identity for this product's users, many of whom sit behind one shared institutional address.
Validation lived in the browser. Profile completeness relied on HTML required attributes and a controller predicate. A direct request, or an administrator editing a record, could persist a "complete" profile with no name and no organization.
Lifecycle email had no eligibility gate. Welcome and follow-up emails keyed off the existence of an account rather than a verified, complete profile. Unverified accounts entered email journeys automatically.
None of these is exotic, and none of them was malicious. They are what happens when controls are designed, written, and reviewed, and never once watched doing their job in the environment where they matter.
For every control, ask: what test would fail if this control were deleted? And for every control that depends on configuration: has anyone seen it reject something in production?
If the answer to either is "no", the control is unprotected. It may work today. It will not survive the next refactor, the next environment change, or the next person who does not know why it is there. Tests that assert wiring (the middleware is registered, the method is called) give false confidence. Tests that assert behaviour (the sixth request in a minute is rejected; a profile without a name cannot be saved through any path; the challenge fails on the real hostname without a valid token) are the only evidence a control exists.
We now treat "unauthenticated endpoint that can cause an email" as its own review category, with layered limits, a challenge verified server-side against the hostname it is served from, and a behavioural test for each layer.
Every gate moved server-side, and every control became provable.
Two things outside the code mattered as much.
Independent review found what a green build did not. Two read-only review passes over our own remediation surfaced a permanent lockout in the one-time-code path, an unbounded audit read, a document embed broken by a tightened content-security policy, and a cleanup selector that could have deactivated a legitimate user. The build was green throughout. Our fixes needed the same scrutiny as the code we inherited.
Real data disagreed with the fixtures. Running an import against the full third-party reference dataset, rather than the small fixture the previous developer had tested with, showed that public domain suffixes were being accepted as organizational evidence and that closed entities were being imported as active. Fixtures encode assumptions; the source encodes reality.
Removing the bot-created accounts was the most dangerous step, because the evidence for "this account was never real" initially lived in short-lived records that a retention job deletes daily. A legitimately verified user could have looked inactive.
The pattern we settled on is portable to any destructive maintenance task:
Controls are claims until a test, a review, or production has watched them fail. When we take responsibility for a system someone else built, we look first for the controls that have never been exercised, and we assume they do not work until shown otherwise. It is why the codebase takeover checklist asks whether authorization is enforced on the server and whether anyone has seen each control reject a request, and why security is part of how we maintain software rather than a separate service.
]]>The checklist has eight parts. Each item is a question with a yes-or-no answer. A "no" is not a reason to refuse the system. It is a line in the plan.
The most common takeover failure is discovering, weeks in, that a critical account belongs to someone who has left.
If any answer is "we do not know", stop and find out before you change anything.
The repository tells you what was intended. Production tells you what is true.
Data is the part of a system you cannot regenerate.
Restore a backup to a safe place during the review. A backup that has never been restored is a hope, not a backup.
You will need to change the system. Find out how dangerous that is.
If the answer to the last question is no, fixing that path is the first engineering task, before any feature.
This is not a penetration test. It is the minimum you must know before you own the system.
Ask about decisions, not code: why this database, why this hosting, what they would change, what they were afraid of. Record the answers.
Write the answers down as a single document, with a "no" list ranked by risk. The ranking becomes the first weeks of work: access and billing first, then backups and deployments, then the fragile parts, then the wanted ones. A takeover done in this order shows the business a new feature later than it hoped and an outage never.
If you would rather have us run this review and take the system over afterwards, that is what our software takeover service is. If you want to run it yourself, the checklist is yours.
]]>This checklist is the set of criteria AL+ checks when productionizing an AI-generated application. It applies equally to a prototype built by hand. Each item is verifiable; do not accept a "probably".
The count matters less than the pattern. A prototype that fails items 1 to 7 is not ready for a single external user, whatever else is true. One that fails only items 23 to 29 is safe to run but expensive to change, which is a problem you can schedule.
We check all thirty before taking responsibility for an application, and we keep what already works: the goal is production readiness, not a rewrite. The service page describes how; the longer argument is in AI-built software still needs an engineer.
]]>Use this list in two directions. If you are leaving a system, deliver these seven things. If you are receiving one, ask for them by name before the previous team's last day, because after that day every item costs ten times more to recover.
Not shared logins: ownership. Repositories, hosting, DNS and registrar, databases, object storage, email delivery, payment providers, third-party APIs, app store accounts, monitoring, and any SaaS the system depends on, each transferred to an account controlled by the company that owns the software. A spreadsheet listing each service, its purpose, the owning account, the payment method, and the renewal date is the single most valuable document in the handover.
One page that answers: what runs where. Production, staging, and any other environments; the servers or platforms behind each; the databases and stores they use; the scheduled jobs and where they are configured; the external services called and the services that call in. A diagram helps, but a list is enough. The test is whether an engineer who has never seen the system can point at every moving part.
How to deploy a change, and how to roll one back. How to restore a backup, with the last date it was rehearsed. How to rotate each secret. How to add an administrator. What to do when the site is down, the queue is stuck, or the database is full. Who to call at each provider. This document is short and boring, and its absence is why most inherited systems have their first outage in the first month.
Not a specification. A few pages on how the system is put together and why: the main components, how a request travels through them, where the data lives, the parts that are fragile, and the parts nobody should touch without reading the notes first. Written by the people leaving, while they still remember.
The decisions that shaped the system and the reasons behind them: why this database, why this hosting, why this framework, why that integration was built in-house. The reasons matter more than the decisions. A decision without its reason gets reversed by the next team for the same reason it was made.
Known bugs, workarounds in place, deferred upgrades, dependencies near end of life, security concerns, and the things that keep the outgoing engineers up at night. An honest list here saves the incoming team months of discovery and protects the outgoing team's reputation when the issues surface anyway.
One or two recorded sessions walking through the environment map, the deployment, and the architecture notes, with questions. Then an agreed window, paid if necessary, during which the outgoing team answers questions by email. A few hours of the previous developer's time are worth weeks of archaeology.
Most incoming teams receive item one partially and nothing else. In that case, run the codebase takeover checklist yourself and write these seven artifacts as you go. The first three are urgent; the rest can follow in the first months.
If you would rather have the incoming team be us, software takeover is the service, and producing this handover for the next team is part of how we finish it.
]]>An owner is one party who can answer three questions about a system without looking anything up for very long:
The owner does not have to be the person who wrote the code. They rarely are. They are the person who is responsible for the system's behavior over time and has the access, knowledge, and authority to act on that responsibility.
An owner is a role, not a permission. Having admin rights on a repository is not ownership. Being the person everyone emails when something breaks is closer, but only if that person can also decide what to fix and when.
We see the same patterns in almost every system we are asked to take over.
The developer left. A freelancer, an early employee, or a small agency built the product and moved on. The code is fine. The knowledge left with them, and nobody was asked to pick it up.
The product was built quickly. A prototype turned into a business faster than anyone planned. Decisions that made sense for a demo are now load-bearing, and nobody remembers which ones.
The product was built with AI. A founder or a small team produced a working application in weeks using AI tools. It works. Nobody on the team can explain why, which is a different problem from it being badly written.
Ownership was split. One vendor runs the infrastructure, another maintains the application, and the customer's own team owns the data. Each party is responsible for their part. Nobody is responsible for the system.
In every case the symptom is the same. Small changes take weeks. Estimates are wide and nervous. Incidents are resolved by restarting things. Every conversation about the software starts with "we would need to look into that."
Unowned software does not fail loudly. It fails through friction.
Each change carries an unknown risk, so changes are batched, delayed, or avoided. Features the business needs are quietly dropped. Security updates are postponed because nobody knows what they might break. When a dependency finally forces the issue, the upgrade is large, urgent, and done by someone learning the system under pressure.
The cost shows up as slower product decisions, as staff who route around the software instead of through it, and eventually as a proposal to rewrite the whole thing. Rewrites proposed for this reason are usually a purchase of ownership at the highest available price.
Ownership starts with understanding, not with changes.
The first weeks are spent reading code, mapping infrastructure, tracing how data moves, and writing down what nobody wrote down. We measure what the system actually does in production, because documentation and reality drift apart. We make a list of what is fragile and what is fine, and we resist the urge to fix things before the list is complete.
Then ownership becomes routine. Dependencies are updated on a schedule. Backups are tested, not assumed. Deployments become boring. Monitoring answers questions before users ask them. Changes have a known cost because someone knows the system.
None of this is glamorous. It is the difference between software that can be changed and software that can only be replaced.
Every piece of software that matters to a business should have a named owner who understands it and answers for it. If that owner is inside your organization, protect their time. If nobody fits the description, that is the problem to solve first; taking over an existing system and maintaining it long term is the work AL+ exists for. Everything else, including whether to modernize, rewrite, or leave the system alone, is a decision an owner makes.
]]>Rewrites are rarely proposed because a system is technically beyond repair. They are proposed because nobody on the current team understands the system, and rebuilding it feels like the only way to get that understanding back.
That is an honest motivation. It is also the most expensive way to achieve the goal. A rewrite recreates the knowledge by recreating the software, and everything the old system learned from years of production, every edge case and every fix, has to be learned again.
The second common reason is frustration. Slow changes, recurring incidents, and an unfamiliar stack make a fresh start attractive. The frustration is real. The remedy is usually ownership, not replacement.
We do not answer the repair-or-rewrite question in the first meeting. We answer it after a review that covers five things.
What the system does. Not what the documentation says or what the founder remembers. What it does in production, for which users, and how often. Many rewrites are scoped against imagined usage.
Where the risk is. Which parts break, which parts nobody touches, and which parts hold data that cannot be lost. Risk is usually concentrated in a small part of the codebase.
Whether it can be changed safely. Is there a way to deploy a change and know it worked? Are there tests, staging environments, backups, and rollbacks? If not, those come first regardless of the final decision, because a rewrite without them is a bigger version of the same problem.
What the stack costs to keep. Frameworks and runtimes reach end of life. Hosting bills grow. Some stacks are hard to hire for. These are real costs, but they are measurable, and they are often smaller than a rewrite.
What the business needs next. A system that needs three small features a year has different requirements from one that needs to double its capability. The rewrite decision depends on the destination, not only on the current state.
Repair is the answer more often than teams expect. The signs:
Repair means establishing ownership, adding the safety equipment (tests around the risky parts, monitoring, reliable deployments), and then improving the system in place, one bounded change at a time. Users see stability first and improvements second. Nothing is thrown away until its replacement is proven.
Some systems do need to be replaced. The signs are specific:
Even then, we rewrite in pieces where we can. A new system that takes over one responsibility at a time from the old one keeps the business running and keeps the decision reversible.
The five review areas above reduce to a small table. Score each row for the system in front of you; the column with the most marks is the recommendation, and a single "replace" in the platform row overrides the rest.
| Question | Points to repair | Points to modernize in place | Points to rewrite or replace |
|---|---|---|---|
| Is the platform supported? | Yes, current versions | Yes, but several upgrade steps behind | No, and it cannot be upgraded |
| Does the data model fit the business? | Yes | Mostly; a few structures fight new features | No; every feature works around it |
| Is there a safe way to change it? | Yes | Partly; tests and rollback exist for some parts | No, and adding them costs more than the parts are worth |
| Where is the risk? | Concentrated in two or three modules | Spread across a layer that can be replaced alone | Everywhere; no coherent design to preserve |
| How much of it is still used? | Most of it | Most of it, with dead areas to delete | A minority; the rest serves cases that no longer exist |
| What does the business need next? | Small features and stability | Significant new capability on the same foundation | A different product |
Repair is maintenance with a plan. Modernizing in place is our modernization service. A rewrite is still done in pieces where we can, with the old system running until each piece has proven itself.
Understand the system, make it safe to change, then decide. Teams that skip to the rewrite skip the part where they learn what they are replacing, and that knowledge is the most expensive thing to rebuild.
]]>This is the sequence we follow when we take over a system in that state.
Before reading a line of code, collect and verify access to everything the system depends on: source control, hosting, domain registrar, DNS, databases, email sending, payment providers, third-party APIs, app store accounts, and monitoring. Confirm that each account is owned by the company, not by a personal address that left with the developer.
Rotate credentials the departed developer had. Do it carefully, one system at a time, with a way to roll back. A rushed credential rotation is the most common way a takeover causes its first outage.
Check billing. Systems fail months after a departure because a card on a forgotten account expired.
The repository tells you what the developer intended. Production tells you what is true. Start there.
This phase produces a map. It usually reveals two or three things that were one bad day away from failing.
Every inherited system has knowledge that lived only in the developer's head. Recover as much as you can while it is recoverable. If the developer is reachable and willing, a few paid hours of questions are worth more than weeks of archaeology. Ask about the decisions, not the code: why this database, why this hosting, what they would change, what they were afraid of.
Then write the operating manual the system never had. How to deploy. How to roll back. How to restore. Who to call at each external provider. Where the secrets live. It does not need to be long. It needs to exist and to be correct.
Before any real work, make a trivial change and ship it through the full path: commit, review, test, deploy, verify, and know how you would undo it. If any step is missing or manual, fix that first. The ability to change the system safely is the foundation for everything else, and it is worth a week of effort even if the change itself is a typo in a footer.
Now the map from step two becomes a plan. Expired certificates, unsupported dependencies, failing backups, and single points of failure come first. They are rarely what the business asked for and always what it needs.
Feature work starts after that. It goes faster than expected, because by now someone understands the system, and estimates are based on knowledge instead of hope.
A takeover done in this order takes several weeks before the business sees a new feature. That is the cost of not doing it, made visible. Teams that skip to feature work inherit every risk the previous developer was silently managing and discover them one incident at a time.
The goal is not to replace the departed developer. It is to make the system not depend on any single person again. The full list of what to inspect is in the codebase takeover checklist, and software takeover is the service when you would rather we did it.
]]>Producing code used to be the expensive part. Now it is often the cheap part. A founder with a clear idea can have a functioning product without hiring a developer, and many do. That is a real change and mostly a good one. More things get built, and more of them get built by the people who understand the problem.
What has not changed is everything that happens after the code exists. Deployment, monitoring, backups, security updates, access control, performance under load, data migrations, and the slow accumulation of changes that a real business demands. This work was never about typing speed. It is about understanding a system well enough to be responsible for it.
We have taken over enough AI-built systems to see the same problems repeat. None of them are about code quality in the usual sense.
Nobody can explain the system. The team can describe what they asked for. They cannot describe what they got. When something breaks, the debugging conversation starts from zero every time.
The design is local, not global. Each feature was generated to satisfy its own prompt. Together they form a system with three ways of doing the same thing, duplicated logic, and data that lives in more places than it should. Each piece is reasonable. The whole is hard to change.
Security is assumed. Authentication, authorization, input validation, secrets handling, and rate limiting are present in the form the tool produced by default, which may or may not be the form the business needs. Nobody checked, because nobody knew what to check.
Operations were never designed. There is a deployment because the hosting platform made one. There are no backups, no alerts, no staging environment, and no plan for the day the database fills up.
Dependencies are frozen. The generated project pinned whatever versions existed that week. A year later, several are unsupported, and upgrading means understanding code nobody has read.
We use them. They are good at producing a first version, at explaining unfamiliar code, and at removing the tedious parts of engineering. The failure mode is not using the tools. It is believing that the tools have taken on the responsibility along with the typing.
They have not. Responsibility for software in production belongs to a person or a company who understands the system, and AI tools do not currently hold that role. Someone has to.
Not rewriting it. Usually the right move is to keep what works and add what is missing.
After this, the AI tools become more useful, not less, because changes land in a system someone understands and can verify.
Code has become cheap. Responsibility has not. Software that a business depends on needs an engineer who understands it and answers for it, however the code was produced. Getting that in place early costs far less than discovering its absence during an incident. The concrete criteria are in the production-readiness checklist for AI-generated applications; productionizing AI-generated software is how we help.
]]>Building is a project. It has a start, an end, a budget, and someone who is proud of it. Maintenance is a line item. It has a monthly figure that someone tries to reduce every year.
This framing makes a strange claim: that the product was finished at launch and everything after is upkeep. No product that has users is finished. Users find the edges. The market moves. Dependencies change under it. The business learns what it actually needed, which is never quite what it specified.
The work that responds to all of that is product work. It happens to occur after launch.
When we maintain a system, the work falls into four kinds, and only one of them is what the word suggests.
Keeping it running. Dependency updates, security patches, certificate renewals, backup verification, capacity, incident response. This is upkeep, and it is not optional. Skipping it is borrowing at a high interest rate.
Keeping it correct. Fixing bugs, yes, but mostly noticing where the software's behavior has drifted from what users need. Reports that used to be right. Integrations whose other side changed. Edge cases that became common cases as the business grew.
Keeping it changeable. Removing complexity that no longer earns its place. Simplifying the parts that every change has to pass through. Improving tests and deployments so that the next feature costs less than the last one. This work is invisible in the product and decisive for its future.
Making it better. Small improvements informed by real usage: a faster page that people visit every day, a form that fails less often, a workflow with one step fewer. These are the highest-return changes in most products, and they are only visible to someone who is paying attention after launch.
A maintenance budget that covers only the first kind produces software that runs, drifts, hardens, and eventually gets rewritten.
If maintenance is upkeep, it can go to whoever is cheapest. If maintenance is product work, it needs people who understand the product and its users, and who are trusted to make decisions.
We think the second view is correct, and it changes how we work. The people who maintain a system are the people who know it best. They should be the ones proposing what to build next, because they see where the friction is. They should have authority to remove things, not only to add them. And their time should be protected from being consumed entirely by the first kind of work, because the other three are where the value is.
When we take responsibility for a system, we plan maintenance as a product function. Upkeep is scheduled and boring. A share of every month goes to keeping the system changeable. And we keep a short list of small improvements drawn from real usage, worked through steadily.
The result is a system that gets better with age instead of worse, and a business that never has to fund a rewrite to buy back the years it spent minimizing the maintenance line.
Launch is the beginning. Budget, staff, and pay attention to the years after it as the product work they are, and most of the reasons for rewriting software go away. This is the shape of software maintenance as AL+ practices it.
]]>