In a post published on the n8n blog by Ophir Prusak, a software engineering veteran turned marketer, a profound analysis is presented on one of the most significant challenges in developing Artificial Intelligence (AI) solutions within organizations. Prusak explains that despite the initial excitement and the exhilarating feeling of launching a new AI project, many builders—especially those from non-technical backgrounds—encounter immense difficulties when the systems they have established begin to expand or fail. Many AI tools are not designed to teach users how the underlying infrastructure works, and when things go wrong, it is not always clear what happened or why. This problem, where a project works well initially but breaks down the road, is known in the software engineering world as the "Day 2 Problem."
What Exactly is the "Day 2 Problem"?
According to Prusak, "Day 2 Problems" are the long-term challenges and issues that emerge when trying to scale and maintain a product or system, after the planning (Day 0) and initial building (Day 1) phases are already complete. These problems do not necessarily occur on the calendar second day of the project, but they are inevitable as the system runs over time and requirements change.
To illustrate the severity of this issue and how it impacts organizations, Prusak shares the story of Dave, a member of the finance team at a company of over 100 employees. Dave is not a software engineer, but he possesses an entrepreneurial spirit and a passion for technology, and he has begun guiding others in the organization on how to build solutions using AI tools. Dave’s week perfectly demonstrates how a project that seems like a resounding success on day one can become an ongoing nightmare in the following days.
Dave's Difficult Week: A Chronicle of a Foretold Collapse
It all began on Monday morning. Dave’s team was drowning under a heavy workload of vendor invoices arriving as PDF attachments via email. Employees had to manually type the data into the system—a tedious, time-consuming process that caused work backlogs of several weeks. Dave decided to solve the problem and built an automation using an AI tool: when a new invoice arrives, the AI scans the PDF, extracts key data, uploads it to the system, and flags anything that looks anomalous. Dave's manager was deeply impressed and even hinted that this project would help him secure a highly-anticipated promotion.
On Tuesday morning, reality set in. The accounts payable team sent Dave an urgent message: three invoices had been entered into the system with completely incorrect amounts. Dave scrambled to figure out what went wrong—did the AI misread the PDFs, or was there an error uploading the data to the system? When he opened his automation tool, he discovered he had no way of knowing. The system did not maintain a log of the AI's operations at each stage; instead, it only displayed the final status message: "Automation complete." Dave made some minor adjustments and tweaks, found the seemingly trivial issue, and fixed it. However, when he ran a test on the updated version, it turned out not to work at all. When he tried to revert to the previous stable version, he discovered there was no version control system—the changes had been made directly on the only existing version. Dave was forced to spend long hours rebuilding the original version from scratch, implementing the fix, and testing it thoroughly before heading home.
By Wednesday, Dave was stuck in back-to-back meetings all afternoon. At 2:00 PM, the automation software required a reset due to an error. His teammate, Marco, offered to step in and handle the issue but had no idea where to start. There was no written documentation explaining how to access the automation editor. When Marco finally found another employee familiar with the system, it turned out the login credentials were tied to Dave's personal email address, with a complex password unknown to anyone else. Dave tried to text instructions from under the table during a quarterly planning meeting, but the attempt failed, and the invoices remained unprocessed until Dave became available at 4:30 PM.
On Thursday, Dave’s manager, who still believed in the project and the time savings it generated, asked to expand the use of the automation to the company’s Austin branch. Dave felt his stomach sink: the entire system was hardwired—it was connected to one specific email inbox, customized to the invoice formats of specific vendors, and linked to a single accounting system. To adapt it for the Austin branch, Dave could not simply modify some settings; he had to rebuild the project almost entirely from scratch. To complete this, he had to cancel his evening plans.
On Friday, everything seemed to be running smoothly until 3:00 PM when a vendor called to complain that their invoice had not been paid. Dave investigated and discovered to his horror that the automation had completely skipped this invoice without processing it. The system failed to parse the format, and instead of raising an error or flagging the invoice, it simply moved on silently. A deeper investigation revealed 11 other invoices that had been silently rejected in the same manner throughout the week. While Dave was busy addressing the visible problems, numerous hidden errors continued to occur under the radar.
How to Solve "Day 2" Problems? The Questions to Ask on "Day Zero"
Prusak explains that the real underlying issue in managing projects of this nature is a lack of awareness. Most of Dave's glitches were not difficult to solve; he was simply unaware of their potential existence until they actually occurred. To avoid this, software engineering offers a clear solution: you must ask the right questions during the planning stage—on Day Zero (Day 0).
The first and most fundamental question concerns project ownership. In 2006, Werner Vogels, Vice President and Chief Technology Officer of Amazon, famously coined the principle: "You build it, you run it." If you build a system, you must clearly define who will be responsible for its ongoing maintenance.
Here are the five core questions Dave should have asked himself on Monday morning:
- How will I track system actions at each step? Dave could not tell whether the AI failed to read the PDF or if the system upload failed because he had no record of the inputs and outputs throughout the process. Any active project requires a level of traceability. In the n8n platform, for example, the visual workflow environment allows users to easily see where things went wrong, providing detailed logging of all inputs and outputs at every execution step.
- How will changes be made, and how can I undo them? Dave edited his only copy of the automation and could not revert. Before launching a project, you must decide where previous versions are saved, whether you can perform a quick rollback, and whether there is a test environment that does not affect the live production system.
- Who else needs access to the system, and what are their permissions? Marco could not help because the access credentials were tied directly to Dave's personal account, and the entire logical structure of the system lived solely in Dave's head. You must establish shared credentials, different permission levels, and basic documentation that allows others to operate the system in an emergency.
- How might the system need to grow and expand? When required to expand the system to another branch, Dave had to rebuild it due to its rigid architecture. Planning ahead for potential growth and expansion is significantly cheaper than retrofitting adjustments later.
- How will I know if the system is working properly or failing? Dave's automation appeared to run fine but was secretly skipping many invoices. A system running in the background must include a monitoring mechanism capable of alerting a human in case of an error or non-processing.
Additional Aspects Beyond Dave's Week
Prusak emphasizes that Dave's difficult week could have been much worse and highlights other critical questions to consider:
- Security: If a hostile actor had breached Dave's system, they would have had direct access to vendor payment data. When dealing with financial information, customer records, or legally protected data, security cannot be an afterthought.
- AI Model Updates: Unlike traditional software, which yields identical output for identical input as long as the code remains unchanged, AI models are prone to variation. Provider-side model updates can alter how a specific prompt is processed, leading to entirely different outputs from the same input. To maintain consistency, methods must be developed to test model behavior over time (a process known in the industry as "Evals"—a form of specialized quality control for AI).
- Operating Costs: Automation might cost just a few cents per single run, an expense that is unnoticeable in the first week. However, as the system scales and becomes a central part of an organization operating across multiple branches, model usage costs can skyrocket, requiring significant budget approvals.
In the professional software engineering world, these aspects are often described using the "-ilities" suffix: maintainability, scalability, portability, and dozens of other similar areas (Prusak notes that during his academic computer science studies, he was taught no fewer than 61 such characteristics). The level of depth required depends on the nature of the project: setting up a simple, temporary application does not require the same rigorous planning as building a complex, stable system intended to run long-term in a large organization.
Prusak explains that while some people can build a backyard shed on their own, they would not attempt to build a nuclear reactor or an industrial bridge. Similarly, there are times when bringing in a professional software engineer is the most sensible step for your organization's AI project. The required expertise depends on the nature of the structure you are attempting to build: is it a simple shed, a two-story house, or a twenty-story building? If you are building a quick and simple application, there is no need to perform such an exhaustive review of dozens of characteristics. But if you want to build a solution that operates with high reliability and handles complex needs, you must prepare accordingly.
Why Doesn't the AI Itself Solve These Problems?
Many users may wonder why Large Language Models (LLMs), which have been trained on vast amounts of software engineering data, do not solve these issues on their own or at least raise these questions upfront.
Prusak explains that LLMs are optimized to provide exactly the output the user requests. If the user is unaware of the need for maintenance and security infrastructure and does not explicitly request it, the model will not assume it on its own. When a user asks an AI to "build me an app that does X," the model focuses on performing that specific task and will not automatically add permission management systems, scaling capabilities, or error notification mechanisms.
To overcome this, Prusak suggests prompting the AI in a way that guides it to ask the right questions. He proposes using the following prompt formulation: "I'm not a professional software developer. I want to make sure this project follows best practices for software engineering: things like maintainability, security, observability, and scalability. Interview me about my project and help me identify what I should be thinking about before I launch."
In conclusion, writing code and building software is an ongoing process rather than a one-time project. Systems and products only reach the "Day 2" stage when they provide genuine value that keeps users returning to them. To ensure a long and stable life for your AI project, it is crucial to prepare for Day 2 on Day Zero.