AI-assisted development, GitHub to Codex, Railway app deployment, Google OAuth setup

I hosted 2 web apps for my local networking groups on Manus! Now What?

What do you do when the platform you built on shuts down—or changes direction overnight?

That is exactly what happened with Manus. My 2 business network website and related tools were originally hosted there. When Manus shifted its business model and direction, it left us—and many other businesses—needing a new path. The underlying risk was clear: platform dependency. When a vendor changes course, your application and data can be left in limbo.

📌 Key Takeaway: Vendor risk is not theoretical. When the platform moves, your business has to move with it—or be ready to move away.

I am not a full-time developer. I have very limited hands-on experience with SQL, GitHub, and modern development tools. I run a business. I care about access, reliability, and the experience my members have—not about memorizing command-line flags or database syntax.

This is not a story about a developer showing off. It is a story about a non-technical business owner who needed to keep a real application alive.

The good news: I simply told Manus I needed to switch to a new hosting platform, OpenAI's Codex. The challenge: I needed to move it off Manus, update its authentication, connect a new database, and deploy it somewhere reliable—without suddenly becoming a software engineer.

This is where Codex came in. With the right constraints and clear direction, Codex literally took over the browser and handled the technical work. It inspected the GitHub project, adapted the authentication, wired up the services, and deployed a private preview on Railway.

💡 Pro Tip: You do not need deep technical skills to use AI effectively. You need clear goals, guardrails, and the willingness to stay in charge of decisions while the AI does the heavy lifting.

The important part is not that AI "built everything for us." The real value came from pairing AI execution with human decisions. Codex handled much of the technical work in GitHub, Railway, and Google Cloud, while I stayed in control of the destination, access rules, accounts, and final approval. If I can navigate this kind of migration with limited technical background, other business owners can too.

Here is how the process worked—step by step—and what other business owners can learn from it if a platform you rely on suddenly changes direction.

Moving an existing website into a modern AI-assisted development workflow can sound more complicated than it needs to be—especially if you do not consider yourself technical. In our case, we started with a specific version of the Business Network application stored on GitHub. We then used Codex to inspect the project, adapt its authentication, connect the required services, and deploy a private preview on Railway.

The important part is not that AI "built everything for us." The real value came from pairing AI execution with human decisions. Codex handled much of the technical work, while I stayed in control of the destination, access rules, accounts, and final approval. If you are a business owner facing similar platform changes, this approach can work for you too.

Here is how the process worked—and what other business owners can learn from it.

We Started With a Known Version of the App

The application already existed in a GitHub repository. Instead of trying to rebuild it from screenshots or recreate it from memory, we identified the exact commit we wanted to use.

That detail mattered. A repository can change over time, but a commit acts like a precise snapshot. It gave Codex a clear source of truth and prevented us from accidentally working from the wrong version.

Codex then inspected the project structure, identified the application framework, reviewed the existing authentication approach, and checked the available build commands. This first inspection reduced guesswork before any changes were made.

The lesson: when transferring an existing app, start with the exact repository, branch, or commit you want. Clear inputs create cleaner results.

We Defined the Deployment Rules Before Publishing

Before deploying, we made two important decisions:

1. The first version would be a private preview.

2. Only approved Google accounts would be allowed to enter.

That kept the project controlled while we tested it. We were not ready to announce a public launch, and there was no reason to expose an unfinished application to everyone on the internet.

This is a good example of AI-Human Harmony. Codex could implement the access controls, but a human still needed to decide who should have access and whether the app was ready for public use.

For our preview, we approved two administrator email addresses. Those addresses were configured as an allowlist rather than hard-coded into public-facing client code.

Codex Replaced the Original Login System With Google

The original project depended on an authentication service that did not fit the new deployment. Codex updated the application to use Google OAuth instead.

That work included:

• Adding Google sign-in and callback routes

• Creating a secure login session after authentication

• Checking the signed-in email against the approved administrator list

• Assigning the approved user an administrator role

• Adding a private-preview screen for visitors who are not signed in

• Documenting the required environment variables without storing real secrets in the repository

We then created the Google OAuth client in Google Cloud, added the Railway domain and callback URL, and registered the approved accounts as test users.

The result was simple from the user's perspective: open the site, choose "Continue with Google," and sign in with an approved account.

Behind that simple button, however, are several security decisions. Client secrets, database credentials, and session keys belong in protected environment settings—not inside source code or a blog post.

We Connected GitHub, Railway, and MySQL

Railway became the hosting platform for the private preview. The application service was connected directly to the GitHub branch containing the Codex changes.

We also added a managed MySQL database and connected it to the application through a protected database URL. Railway received the production settings the app needed, including:

• The public application URL

• The Google OAuth client configuration

• The administrator email allowlist

• A secure session secret

• The production database connection

• The production runtime mode and port

Once these settings were staged, we deployed the application.

This setup gives us a repeatable workflow. Future approved code pushed to the connected branch can trigger a new deployment without manually transferring files between systems.

The First Deployment Was Not the Final Answer

The most useful part of the process was the validation—not the first green deployment indicator.

The first live check exposed two issues:

• A leftover startup check still expected the project's old authentication service.

• The public Railway domain was pointing to a different port than the application was using.

Codex inspected the live deployment logs, located the obsolete authentication guard, removed it, tested the change, and pushed a correction to GitHub. We then aligned the application port with Railway's public domain and redeployed.

After that, the site returned a successful response and the Google login route redirected to the correct OAuth flow.

This is an important reality check for anyone using AI for development: generated code is not the finish line. You still need to build it, deploy it, inspect the logs, test the live URL, and correct what the real environment reveals.

What Codex Handled—and What I Still Controlled

Codex helped us:

• Inspect and understand the existing codebase

• Make focused code changes

• Run available checks

• Commit and push the work to GitHub

• Configure the Railway service and database

• Set up the Google OAuth connection

• Read deployment logs and diagnose problems

• Verify the live site and authentication redirect

I remained responsible for:

• Choosing the correct source version

• Deciding that the preview should remain private

• Selecting the approved administrators

• Verifying the Google account

• Authorizing deployment

• Reviewing the final experience before any public launch

That division of responsibility is exactly how I believe AI should be used. AI is not here to replace human leadership. It is here to give good people more leverage.

What Business Owners Can Take From This

You do not need to become a full-time software engineer to benefit from tools like Codex. You do need to provide clear goals, make the important business decisions, and insist on validation before launch.

A practical AI-assisted deployment process looks like this:

1. Identify the exact source of truth.

2. Define who should have access.

3. Let the AI inspect before changing anything.

4. Keep credentials outside the codebase.

5. Deploy a private preview first.

6. Test the real production environment.

7. Review the result before going public.

That is how AI becomes useful in operations: not as a flashy demo, but as a partner that shortens the distance between a decision and a working result.

If your business has an existing website, internal tool, or unfinished application sitting in a repository, it may be closer to launch than you think. The first step is not rebuilding everything. It is understanding what you already have and creating a controlled path to the next version.

Want help turning an existing website or internal tool into a working, AI-supported system? Contact AI Growth Plan to map the next practical step.