They asked for two-factor authentication. We started somewhere else.

Engineering notes from an AI-built construction ERP, four months in and already running the company.

Where they were

A construction company had built an ERP using an AI development platform. After four months of work, 28 employees were already using it every day to run the business.

The system includes several modules, including task assignment, cost estimation, takeoff, and hour logging for staff on site. It works. People log in every morning and do their jobs in it.

The plan is to turn it into a SaaS product and eventually make it available to other construction companies. At the time we started, it was still designed around a single company rather than multiple organizations.

They contacted us because they wanted to add one-time passwords at login, along with email and SMS notifications. As we started working through those requirements, we found that some of the underlying foundations also needed attention. That widened the scope of the work.

What we found

We reviewed the code and the product before changing anything. Some opportunities were visible in the codebase itself. Others only became clear when we tested the product and looked at how it was deployed.

The deployment process needed a safer foundation

There was no separate staging environment or established deployment workflow. Changes could go directly to the system the team was using every day, which made testing and rollback harder than they needed to be.

We also found some differences between branches. Work that had been developed in different places was not always fully aligned, making it harder to know which version represented the current state of the product.

There were also a few production dependencies that were not fully represented in the repository. One example was a production email function that the application relied on but that was not present in the source code we had available. That meant part of the running system was outside the normal development workflow.

Some credentials needed to be secured

Database connection credentials had previously been committed to the repository. That meant anyone with access to the repository history could potentially access those credentials.

Removing the file alone would not be enough, because credentials can remain in git history. The credentials therefore needed to be rotated and moved into the proper environment configuration.

Login had several areas to improve

There were two login entry points, at `/auth` and `/login`, so both needed to be considered when improving authentication.

There was no self-service password reset for users. An administrator had to handle it manually, which becomes increasingly difficult as the product grows.

Email login also had no second verification step. A correct password was enough to complete the login.

We found a few smaller edge cases around signup and account handling as well, including an existing-email scenario where the user could receive a success message even though a new account had not actually been created.

The authentication emails were also being sent from the platform's default sender rather than the company's own domain.

Some features needed a proper backend

Parts of the application were relying on browser local storage rather than persistent backend storage. That can work for a prototype, but it means the data belongs to a particular browser and device rather than to the user's account.

For a production system, important business data needs to have a reliable source of truth that survives changing devices, clearing browser data, and normal product growth.

Some areas of the code needed to become easier to maintain

The takeoff canvas had grown into a very large file. Files of that size make changes harder to reason about and increase the chance that a small change can have an unexpected effect elsewhere.

This is one of the challenges that can appear as an AI-built application grows: the product can move very quickly at first, but the structure underneath eventually needs the same attention that any production software needs.

What we changed

We started with the foundations, not just the feature list.

We moved the project off the original build platform to GitHub and Vercel, giving the client ownership of the code and a clear record of deployments.

We migrated the database to a separate Supabase account under the client's control.

We established main and staging branches with a deployment workflow, so changes can be tested before they reach employees.

We then turned the findings from the initial review into a structured set of improvements rather than waiting for problems to appear in production.

What would have broken

None of these issues had to cause an outage to be worth fixing. That is the point.

A credential can remain unused until the day it matters. Browser storage can work perfectly until someone changes devices or clears their data. A missing staging environment becomes important the first time a change needs to be tested safely. A large, tightly coupled file becomes a problem when the product needs to change quickly.

The risk with an AI-built product is not that it fails immediately. It is that it can work well enough to gain real users and support real business plans before anyone has taken a close look at the foundations underneath it.

The multi-tenant challenge sits above all of this. Making the product available to other companies means ensuring that each customer's data is properly separated, and that has to be reflected in the database and application design. It is much easier to make that decision early than to retrofit it after the product has grown.

The point

They asked us for two-factor authentication and notifications. That work is real, and we are doing it.

But the work also showed why production readiness is bigger than adding the next requested feature. Authentication, deployment, data storage, credentials, and maintainability all become part of the product once real people depend on it.

If you built something with AI and it works, that is a real achievement. The next question is whether the product is ready to handle more customers, more data, and more change.

You cannot answer that question by using the product alone. Someone has to look underneath.