Keep a named person in your business responsible for priorities and accepting the result. An external team can design, build, and operate software, but it still needs decisions about your users and business rules. If nobody can make those decisions, adding developers will not resolve the problem.
Provider labels differ. Ask who performs each job and who can approve the result rather than assuming a “dedicated team” includes everything you need.
On a narrow screen, scroll the table sideways to read all columns.
| What you need | What the external provider does | What you must arrange internally |
|---|---|---|
| Additional engineering capacity | Works on tasks within your existing delivery process. | Technical direction, task readiness, review, release, and product decisions. |
| Delivery of a bounded project | Coordinates the agreed design, implementation, testing, and release work. | A decision-maker, access to relevant users, acceptance criteria, and timely answers. |
| Continued ownership of an existing system | Takes on explicitly agreed maintenance and development responsibilities. | Business priorities, approval limits, and an agreed route for support and incidents. |
These are practical distinctions, not standardized packages. A project provider may exclude hosting or support. A maintenance provider may exclude new development. Record those boundaries before comparing proposals.
If your main problem is a lack of internal engineering leadership, buying individual developers leaves that gap open. Ask explicitly whether the engagement includes technical direction and coordination. If you already have those functions, extra implementation capacity may be enough.
An external partner is worth considering when you can describe a useful outcome, appoint someone to make decisions, and provide the access or information needed to deliver it. For example, you may have a known operational bottleneck but lack the engineers to build the solution.
Pause the build when the larger uncertainty is whether people need the product, whether an existing tool can do the job, or whether a required integration is possible. Resolve the uncertainty first. Our MVP versus prototype guide explains how to choose a smaller experiment before commissioning a working product.
Do not assume outsourcing will be cheaper. Compare the whole proposed engagement: discovery, implementation, your team's review time, integrations, release, running costs, and work after launch. A lower hourly rate cannot tell you how much work is included or whether two proposals promise the same result.
For each item below, write four things: the provider's job, your business's job, the evidence you will review, and what is excluded. An unanswered item is a question to resolve, not an implied commitment.
The GOV.UK guidance on working with contractors provides a useful reference for knowledge transfer and limiting access to what the work needs. Its government procurement process is not a requirement for your private software project.
Technical control and legal rights are separate questions. Access to a repository does not settle rights to the code or third-party components. Record the agreed rights and any licensing constraints alongside the practical ability to continue the work.
Consider a hypothetical customer portal. A customer submits a service request, an operator accepts it, and the customer sees the decision. This is an illustration, not an AL+ client result.
A proposal that promises “a portal with three screens” leaves substantial questions open. Use the worksheet to ask who defines the approval rules, checks customer isolation, connects notifications, releases the application, and handles a failed notification.
For one reviewable milestone, you could require:
Ask the provider to identify what it can demonstrate with test data, what needs access to another system, and which unknowns prevent a dependable estimate. This makes the first commitment reviewable without pretending that the entire project is already known.
Request a walkthrough of how a relevant kind of change is reviewed, tested, released, and handed over. A provider can use its own demonstration system or an anonymized example; it should not need to disclose another client's private code to explain its process.
Ask what happens when a requirement changes, an engineer becomes unavailable, or a dependency fails. For US or Canadian businesses working with a remote provider, agree the actual working-hour overlap and how decisions move forward outside it. Geography alone does not establish a usable communication plan.
For security, ask what practices and checks apply to your data and release. NIST's Secure Software Development Framework offers a vocabulary purchasers can use in discussions with suppliers. Referencing it is not proof that a provider follows it, and it does not establish an AL+ certification.
For the project requirements themselves, use the custom software development brief. Keep that brief separate from the worksheet: one describes the software you need; the other assigns the work needed to deliver and own it.
AL+ provides custom software development for web applications, SaaS products, APIs, and internal tools, with maintenance after launch. We work remotely, in English or Romanian. We agree the delivery and operating responsibilities in writing before we start.
Email AL+ about software development outsourcing with the workflow, what already exists, who can make product decisions, the responsibility you need us to take, and any budget or timing constraints. Send a description first; do not include passwords or private customer records.
]]>This guide focuses on native iPhone and iPad projects, the scope of our iOS app development service. It helps you describe the app and compare proposals without relying on a generic price range.
Start with one journey: the user opens the app, does a useful task, and receives a result. Explain who the user is, how often they repeat the task, and what happens when they make a mistake.
A simple-looking screen may need complicated rules. A log that works offline needs decisions about storage and later updates. A paid feature needs purchase, restoration, and access behavior. A camera feature needs permissions and a usable path when access is denied.
Separate essential behavior from later ideas before asking for a quote.
An estimate should address the requirements that apply to your product:
Not every app needs every item. The goal is to identify the relevant work before it disappears from the estimate.
If the app uses an existing service, include its API documentation and explain who maintains it. Check whether a test environment and the required permissions are available.
If the backend does not exist, it is part of the project. The app interface and the server are different work, but their behavior must agree. Specify what happens when the connection fails or an operation is retried.
For a product with online customer workflows and billing, also consider the SaaS development scope.
Agree who owns the Apple developer account, who can sign and submit builds, and who prepares the store information and review responses.
Release work can include screenshots, product descriptions, privacy information, testing access, and explanations for reviewers. Apple's review decision remains outside the developer's control. A proposal should not promise approval on a fixed date.
Keep account ownership and access clear so that another developer can maintain the app later.
For an existing app, provide its store link, source access, backend information, and the current issue or desired change. Establish whether the project builds reproducibly and whether signing and account access are available.
A small requested change can reveal an outdated dependency or a missing release process. Ask the provider to distinguish the feature work from the work needed to ship it safely.
Our software takeover service covers this review, while maintenance covers ongoing releases and improvements.
Ask what is included, what is excluded, how completion will be verified, and what you receive at handover. Compare the same user journey and platform support in each proposal.
Budget separately for third-party services and continuing maintenance. Obtain current account and provider prices directly from their owners; they are not fixed development fees.
A focused MVP can reduce the initial feature scope while retaining the release and operating work a real product needs.
Send the intended users, core journey, supported devices, relevant integrations, any existing app or prototype, and your budget and deadline constraints. If it is a fitness product, describe the records and personal data it handles; see fitness app development.
Email AL+ about your mobile app. You do not need a finished specification to start the discussion.
]]>There is no single budget for every minimum viable product. A first release with one user role and an existing data source is different from a product with billing, several permissions, and an integration nobody has checked.
Write down who the user is, where they begin, what they do, and the result they receive. Include the important failure cases. If a user pays and the product cannot provide the result, what happens next?
This journey is the starting point for MVP development. It is also the basis for deciding what can wait. A feature is not essential merely because it appears in a competitor's product.
For example, a scheduling product might first let a customer choose an available slot and receive confirmation. Staff administration, cancellation behavior, time zones, and notifications still need decisions. A large analytics dashboard may be able to wait.
Ask the developer to identify the work in each area:
These are budget components, not six mandatory contracts. Their purpose is to show what the proposal includes.
An estimate should say which systems already exist, who can grant access, what data is available, and what still needs a technical check.
If an integration has no usable test environment, do not treat its behavior as settled. If a prototype works only on its creator's computer, leave room to establish the build and release process.
Ask how uncertain work will be investigated and how the estimate changes when an assumption is wrong. A fixed scope still needs a process for changes.
Two proposals are comparable only if they cover the same behavior and responsibilities. Ask each provider:
A lower quote that excludes release, tests, or handover may describe a different product.
Development is only part of the budget. Hosting, email delivery, monitoring, storage, paid APIs, payment fees, and maintenance may continue after launch. Not every product needs every provider.
Ask for the expected services and the assumptions behind their use. Third-party prices can change; obtain current prices from the providers before committing to a budget. Define who pays each bill and who owns each account.
For a subscription product, review SaaS development. For a native app, review mobile app development cost.
Include the intended users, one complete journey, any existing prototype, integrations, required deadline, and your budget constraint. A budget band helps a provider propose a realistic scope; it does not replace an estimate.
Use the custom software planning guide to prepare the brief.
Email AL+ about your MVP. Include what the first release must let a user do and what you need to learn from it.
]]>These are different purchases. A polished demonstration does not necessarily include the data handling, permissions, release process, or support that a working product needs. Before comparing development proposals, name the question you want the work to answer.
The labels vary between teams. Agree the intended result rather than relying on the name in a proposal.
On a narrow screen, scroll the table sideways to read all columns.
| Deliverable | Question it answers | What you should be able to observe | What it does not establish |
|---|---|---|---|
| Prototype | Can users understand and complete this proposed interaction? | People try a limited journey; you see where they hesitate or misunderstand it. | Reliable integrations, production operation, or willingness to pay. |
| Proof of concept | Can a specific technical approach work under the relevant constraints? | A narrow experiment demonstrates a capability, such as reading the required data from a provider. | A complete product or a usable customer experience. |
| MVP | Can a small working product deliver the intended value to its first users? | Real users complete the core task; you collect feedback and observe use. | Product-market fit, profitable acquisition, or readiness for every future customer. |
A prototype can be a paper sketch, a clickable design, or a limited coded interface. Its usefulness comes from what you learn, not how much code it contains. The GOV.UK alpha guidance makes the same practical distinction: test risky assumptions with prototypes rather than treating experimental code as production software.
An MVP can be offered to a small invited group. It does not need every feature, but the people using it need a way to complete the promised task and obtain help when it fails.
Ask what could make the next development commitment wasteful.
You do not have to buy all three in sequence. If the workflow is already understood and the technology is established, a separate prototype may add little. If a required integration cannot work, building the rest of the product first is the wrong order.
Consider a hypothetical booking product. Customers need to choose an available appointment, receive confirmation, and change the booking if necessary. This is an illustrative example, not an AL+ client result.
A prototype could show appointment selection, the confirmation screen, and the cancellation path. Test whether people understand the choices and whether staff can use the proposed administrative view. The appointments and confirmations can be simulated if that is explained to participants.
A proof of concept could examine the calendar provider. Can the application read availability, create a booking, and recognize a conflicting change using the access the business can obtain? Document what the experiment tested, the environment used, and what remains untested.
An MVP could let a limited group make real bookings for one service at one location. It would also need the relevant rules for time zones, conflicts, cancellation, staff access, and failure recovery. A large reporting dashboard may wait; preventing two people from booking the same slot may not.
The decision is about the uncertainty and the promised outcome. “Only five screens” is not enough to distinguish those scopes.
Fill in these six lines. If you cannot answer one, record it as an open question rather than an assumption.
For the booking example, an acceptance statement might be: “An invited customer can book a genuinely available slot, receive confirmation, and cancel it; staff can see the change.” That describes product behavior. “The app has a booking screen” describes an interface and leaves the important work unresolved.
Use the MVP development cost guide to compare estimates for the same deliverable and exclusions.
Small scope does not remove the responsibilities created by real users and real data. Identify which apply before launch:
Those requirements should match the actual release. Do not add infrastructure for imagined scale, but do not omit a recovery path for information you cannot afford to lose. The GOV.UK beta guidance offers a useful model: invite a limited group, learn from real use, and plan the capacity to support that learning.
Sometimes. First inspect what the prototype actually contains. The interface may be reusable while simulated data, temporary authentication, or local-only setup must be replaced. Code written for an experiment may be cheaper to discard than to make dependable.
Ask the developer to separate reusable work, missing production work, and unresolved assumptions. An AI-built prototype needs the same review; a convincing demo is evidence that the demo works, not that the product is ready for customers.
AL+ provides MVP development for founders who need one complete first journey and clear ownership after launch. Send the six-line brief, any existing prototype, and your budget or timing constraints.
Email AL+ about your prototype or MVP. We can discuss which deliverable addresses the question you need to answer.
]]>Use this checklist before asking for a proposal. It helps you compare what providers will deliver, rather than comparing prices for different interpretations of the same idea.
Write one sentence: “A [user] needs to [complete a task] so that [useful outcome].” For example, an operations manager needs to approve a booking without copying information between three systems. This is an illustrative workflow, not a client result.
List the other people involved. A customer, an administrator, and a finance operator may need different permissions even when they use the same record.
Explain the current process, including spreadsheets, emails, and manual checks. Name the step that costs time or causes mistakes. Include one anonymized example of the input and the expected output.
Do not send passwords, customer records, or production credentials in the first email. Describe the systems involved; arrange appropriate access after the project is agreed.
Choose a workflow a real user can finish. Specify what starts it, what the software does, and how the user knows it succeeded. Include the failure path: what happens when input is wrong, an approval is refused, or an integration is unavailable?
Put everything else in a separate later list. A small first release can have fewer features while still needing reliable data handling, access control, and a way to recover from failure.
Name each external service, the information exchanged, and who controls access. Say whether the provider has a documented API and whether test access exists. These are questions to resolve, not capabilities to assume.
If data must move from an old system, describe its format, approximate size, quality problems, and the period when both systems may need to run. Migration is work beyond building the new screens.
Include budget limits, any fixed date and its reason, required accessibility, data location constraints, and who will use the system. If requirements need specialist legal or security advice, identify who will provide it.
For remote work, agree how decisions will be recorded, who can approve scope, and what overlap in working hours is necessary. A stalled decision can delay delivery even when implementation is straightforward.
Software development cost depends on the workflows, permission rules, integrations, data work, and operating requirements. The same screen count can hide very different amounts of work.
Ask each provider to separate known scope from assumptions. Compare these five items:
A price without those boundaries is difficult to compare. This checklist does not provide a universal project price; a credible estimate needs the actual requirements.
Write checks in user terms: “An operator can approve a request, the customer receives the correct update, and the decision is recorded.” Define representative examples and errors the system must handle.
Agree how you will see progress and test releases. Also agree who owns the repository, infrastructure accounts, documentation, deployment process, and backups. The software handover checklist describes the artifacts you should be able to receive.
Your first email can be short: the user, the workflow, what exists today, the important integration, and your budget or timing constraints. A finished specification is not required.
AL+ provides custom software development services with ownership after launch. Email paul@alplustech.com with those details to discuss your project with the people who would build it.
]]>If you are comparing providers, ask each to price the same scope. A monthly figure that excludes deployment, dependency updates, and incident investigation cannot be compared with one that includes them.
The original build price does not tell a new provider whether your backups restore, your dependencies are supported, or your payment integration fails quietly. Before treating any estimate as a commitment, establish what runs in production and which parts need attention.
Write down:
If the original developer has left, use the codebase takeover checklist to identify missing access and knowledge. You can collect this information without choosing a new provider first.
A new team needs to understand production, check access, establish a repeatable deployment, and verify recovery. Missing documentation or an unsupported framework can add work before normal maintenance begins.
Ask what the initial scope delivers and what would trigger a revised estimate. Keep it separate from the ongoing monthly commitment so both parties can see the cost of inheriting the system.
List the planned work: dependency and security updates, release checks, backup restoration tests, monitoring, and operational documentation. Agree how often each happens and what evidence you receive.
Hosting, database, email, and other provider bills belong in the operating budget too. State whether you pay those directly or through the maintenance provider. Engineering time and infrastructure bills are different costs.
Specify the coverage hours, time zone, contact route, and what counts as urgent. Response time means someone starts assessing the problem; it does not mean the problem is resolved within that time.
For a US or Canadian business using a remote team, discuss overlap explicitly. Do not assume a monthly maintenance arrangement includes overnight or weekend response.
Separate bug fixes from changes to how the product works. A new integration or a large workflow change needs a scope, even when the same team does both maintenance and development.
Agree how work is prioritized, how estimates are approved, and what happens when the month contains more work than the available capacity. That discussion matters more than the label on the package.
Fill in these lines before comparing quotes:
For each quote, ask the provider to mark what is included, excluded, or not yet known. Ask how unused capacity and work above the agreed scope are handled. Do not assume either rolls over or is automatically billable.
A provider may reasonably offer a narrow service. The risk is a gap nobody owns: application support without dependency upgrades, monitoring without a person receiving alerts, or backups without a restoration check.
Ask who is responsible for each gap. You might keep a task internally, hire a specialist, or include it in the maintenance scope. The useful outcome is explicit ownership.
If the application is supported and easy to deploy, recurring upkeep may be enough. If a framework upgrade, deployment repair, or data migration is needed first, scope that work separately.
Our repair or rewrite guide helps distinguish targeted work from replacement. The maintenance budget should reflect that decision rather than hide a modernization project inside routine upkeep.
AL+ provides software maintenance services for existing web applications and SaaS products, including systems built by another developer or agency.
Email paul@alplustech.com about software maintenance. Describe the application, its stack if known, your country, the current problem, and the support hours you need. Send a description first; keep passwords, API keys, and customer data out of the email.
]]>You do not need to decide on a full rewrite before asking for help. You need a description of the application, an example of what goes wrong, and an engineer who can explain the system before changing it.
“Clean up the code” can mean fixing a payment failure, preventing one user from seeing another user's records, or making deployments repeatable. Those require different work and different checks.
Start with one example. Record what you did, what you expected, what happened, and whether you can repeat it. Mention whether the app has paying users or holds real customer data. Keep that data out of screenshots and emails you send to potential providers.
Include:
Unknown answers are useful too. Write “unknown” rather than guess. Arrange access separately after agreeing who should receive it and why.
A first scope should name the area being inspected, the proposed output, and how the result will be verified. For example: reproduce a cross-account access problem, repair the server-side permission check, and demonstrate that account A cannot retrieve account B's record.
That example describes a task, not a claim that your app has this defect. The same approach works for a failed deployment or a background job: establish the actual behavior, fix the cause, and repeat the flow.
Ask which findings could expand the scope. If the repair exposes a wider problem, the next work should be discussed rather than silently added.
Ask how the provider will verify that one user cannot read or change another user's data. A hidden interface button is not evidence of a server-side restriction.
A configured backup is only part of the story. Ask whether a backup has been restored in a separate environment and how the restored data was checked.
Another engineer should be able to deploy from the repository using documented configuration. Discuss rollback, including whether a database change can be reversed safely.
Tests should exercise the flow that failed and assert a concrete result. A successful build alone does not establish that the payment, permission, or user workflow now works.
Ask for known problems, deferred work, and limits of the review. Repairing one defect does not establish that the entire app is ready for production. The production-readiness checklist gives you a broader set of questions.
A repair is worth considering when the application serves a useful purpose and its problems can be isolated and verified. Replacement may be appropriate when the existing design prevents the required behavior or the system cannot be operated responsibly within your constraints.
Ask the provider to explain that decision against the actual app. “AI wrote it” is not enough information to justify either choice. Our repair or rewrite guide describes how to examine the tradeoffs.
Agree who receives alerts, maintains dependencies, controls provider accounts, and handles future changes. Cleanup is a bounded intervention; keeping the application dependable is ongoing work.
You can continue using AI coding tools. Changes still need review and verification against the system you now understand. Keep deployment instructions and the list of known risks available to whoever works on it next.
AL+ assesses and repairs existing applications and maintains them afterwards. The work starts from the existing system and keeps what is useful.
Email paul@alplustech.com about your AI-built app. Send the short brief above and the problem you need solved. We can discuss fit and the next step from that context; a cost or deadline needs an agreed scope.
]]>“People will use it on mobile” does not settle the decision. A web application can work in a mobile browser. “We need offline access” is not enough either: offline behavior must be designed, and some web applications can support it. The useful question is which approach can deliver your actual workflow with acceptable constraints.
A web application runs in a browser. Users can usually reach it through a URL, and the interface can adapt to a phone, tablet, or desktop. Its capabilities depend on the browsers and devices you support.
A native mobile application is built for a particular platform, such as iOS. It is installed on the device and uses that platform’s interface conventions and available APIs. Supporting another native platform creates additional delivery and verification work.
A progressive web app, or PWA, uses web technologies with additional capabilities such as installation and designed offline behavior. MDN’s PWA documentation explains those possibilities. Availability and behavior still need checking on your target devices; “PWA” is not a promise that every native feature works everywhere.
Use the requirements below to choose the first product surface.
On a narrow screen, scroll the table sideways to read all columns.
| Requirement | Web app: what to check | Native app: what to check |
|---|---|---|
| Customers arrive through a link | Can they complete the journey in the supported browsers without installation? | Is installing an app an acceptable step before they receive value? |
| Work spans desktop and phone | Are the layouts and interactions suitable for both? | Will desktop users also need a web interface? |
| A device feature is essential | Is the required API available and reliable on the exact browsers you must support? | Does the platform provide the capability, and what permissions and restrictions apply? |
| The connection is unreliable | Which actions work offline, and how will stored work synchronize? | The same questions apply; installation alone does not make server-dependent actions work offline. |
| Several platforms are required | Verify behavior across the supported browser and device combinations. | Define each platform’s scope and the tests, release work, and maintenance it needs. |
| Releases must change frequently | Plan deployment, compatibility, and recovery for changes to the running service. | Also account for distribution, review where applicable, and users on older app versions. |
Do not treat these as a score where the most ticks win. One essential capability can determine the approach. Several preferences may not justify the additional product surfaces.
A customer approval portal: customers receive a link, review documents, approve work, and sometimes complete the task on a phone. Staff manage the records at a desk. A responsive web application is a reasonable first candidate. Before building an app, test whether installation would improve the important journey at all.
A field recording tool: staff capture information throughout the day in places with poor connectivity. The product needs specific device behavior, local records, and later synchronization. Evaluate a native app and a PWA against those exact requirements. A small capability experiment on the actual devices may resolve the choice more usefully than a generic feature comparison.
These are hypothetical workflows, not claims about AL+ client results. The first favors easy access across devices; the second makes device and connection behavior central. Neither determines the architecture of every product in its category.
Describe what happens before, during, and after the connection fails:
A cached screen and an offline business transaction are different requirements. For example, displaying a previously loaded appointment does not establish that a new booking can be confirmed without reaching the system that owns availability.
Native and web implementations both need decisions about data, conflicts, and recovery. Check the relevant platform documentation and verify the critical behavior rather than promising it from a technology name.
An installed app can still depend on accounts, shared records, payments, notifications, and administrative tools running elsewhere. A web application can need those same services.
For either approach, identify which backend already exists, who controls it, which interfaces are available, and what must be built. Moving the interface to a phone does not resolve an unreliable integration or unclear data ownership.
Include the administrative workflow. If someone must correct a record or support a customer, decide how they will do it. A mobile customer experience and a web administration interface can be different surfaces of one product, but both belong in the scope.
Ask each proposal to separate the shared product work from the platform work:
There is no reliable universal percentage by which one approach is cheaper. An existing backend, a required device capability, or a second interface can change the comparison. Compare the same useful release rather than two screen counts or hourly rates.
Our mobile app cost guide explains the work in a native iOS estimate. It is a scope checklist, not a promise of a standard project price.
Write these six lines before asking a developer to choose a stack:
If a capability could change the decision, request a focused technical check before a full build. If the uncertainty is how people use the interface, a prototype may be the right first step.
AL+ builds custom web applications and native iPhone and iPad apps, with responsibility for the connected services and maintenance after launch. We can discuss the first platform around the task, target devices, and existing system.
Email AL+ about your web or iOS project. Send the six-line brief so the conversation starts with the requirements that determine the work.
]]>Describe the important workflows, expected use, integrations and constraints. A reporting tool used by a small team has different demands from a service processing a continuous stream of events.
Ask the developer which requirement makes the proposed language a good choice. An existing team, a library the application needs, or compatibility with a current system may matter more than a performance comparison.
A benchmark measures a particular implementation on particular hardware, with a particular workload. Different database access, caching or error handling can change the result. Throughput without correct results does not establish that a system meets its users' needs.
Before paying for a migration on performance grounds, reproduce the problem in your application. Identify where the time goes and compare changes under the same conditions. The useful result is the improvement to the workflow that matters to the business.
A language choice also determines which developers can review changes, which dependencies you rely on, and how releases work. Ask who will maintain the system after launch and how another developer would take over.
Our experience includes Ruby on Rails, Elixir, Rust and native iOS development. We choose within that experience according to the project. We discuss compatibility and maintenance before proposing a new stack.
An application written in Rails or Phoenix does not need a rewrite because another language is popular. Improvements to queries, deployment, monitoring or a specific slow component may address the actual problem with less disruption.
Our modernization service begins with the existing system. We compare targeted improvements and replacement against the work you need the application to support.
You do not need to choose a programming language before contacting us. Describe the task, the users, what already exists and any constraints. We can discuss the technical choices as part of scoping a custom software project.
]]>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.
The same patterns tend to show up when a system has lost its owner.
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.
The same problems repeat across AI-built systems. 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.
A tool does not take responsibility for operating the application. Agree who understands the system, checks proposed changes, receives alerts and can restore the data. Those responsibilities need named people and an agreed scope, however the first version was produced.
Not rewriting it. Usually the right move is to keep what works and add what is missing.
Future changes can then be checked against a system the team understands.
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; our application repair service starts with the actual problems in the existing application.
]]>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.
]]>