DEV Community: Robert Saylor

How to Build a ChatGPT GPT Action with Laravel, OAuth, and Two Separate Applications

Robert Saylor — Mon, 24 Aug 2026 14:46:52 +0000

What if your users could operate your Laravel application simply by talking to ChatGPT?

Not by copying information from ChatGPT into your application.

Not by embedding another chatbot into your website.

I mean allowing ChatGPT to securely authenticate as a user and execute real actions against your Laravel API.

I recently worked through exactly this type of integration while building a GPT Action for a production Laravel application.

The final architecture allows a user to say something as simple as:

Show me my connected social channels.

ChatGPT authenticates through OAuth, calls the Laravel API, resolves the OAuth identity to the correct application user, verifies the requested scope, and returns that user's actual data.

The architecture looks roughly like this:

ChatGPT
    ↓
Custom GPT Action
    ↓
OAuth 2.0
    ↓
Laravel Authentication Application
    ↓
Laravel Passport
    ↓
Account Mapping
    ↓
Main Laravel Application
    ↓
Application API
    ↓
User's Data

It works.

Getting all of those pieces working together, however, exposed several implementation details that aren't immediately obvious when you start experimenting with GPT Actions.

In this article, I'll walk through the architecture, OAuth flow, OpenAPI schema, Laravel Passport configuration, account linking, scopes, debugging, deployment problems, and one very important ChatGPT account limitation you should understand before planning to distribute a GPT publicly.

And if you're reading this because you want to add ChatGPT Actions, AI integrations, OAuth, APIs, or other custom functionality to an existing Laravel application, that's exactly the kind of work we do at Custom PHP Design.

👉 Custom Laravel and PHP Development:

Custom PHP Design

What Is a GPT Action?

A custom GPT can do much more than generate text.

GPT Actions allow a GPT to communicate with external APIs.

That means a GPT can potentially:

Retrieve customer account information
Query application data
Create records
Update records
Start workflows
Publish content
Retrieve reports
Schedule tasks
Interact with internal business systems
Trigger Laravel jobs and services
Work with existing SaaS functionality

The GPT learns what your application can do through an OpenAPI specification.

For example:

openapi: 3.1.0

info:
  title: "Example Application API"
  version: 1.0.0

servers:
  - url: https://example.com

paths:
  /api/v1/channels:
    get:
      operationId: getConnectedChannels
      summary: Get the authenticated user's connected channels

      responses:
        '200':
          description: "Connected channels"

Once imported into the GPT Action configuration, ChatGPT understands that it has an operation named:

getConnectedChannels

The model can decide to call that operation when the user asks something like:

What accounts do I have connected?

This creates a very interesting interface for existing Laravel applications.

Instead of forcing every workflow through forms, dashboards, and navigation menus, some workflows can become conversational.

That doesn't mean replacing your application interface with ChatGPT.

It means giving customers another way to interact with the functionality you've already built.

If you already have a mature Laravel application and want to explore this type of integration, visit:

Custom PHP Design

Why OAuth Matters

For public application data, a GPT Action can potentially operate without user authentication.

But most useful SaaS applications contain user-specific data.

Suppose two customers use your GPT.

Customer A should see:

Customer A's data

Customer B should see:

Customer B's data

Customer A must never be able to access Customer B's information.

The GPT therefore needs to authenticate each user independently.

That's where OAuth comes in.

A typical OAuth Action requires:

Client ID
Client Secret
Authorization URL
Token URL
Scopes

For Laravel, Laravel Passport is a natural option because it provides a full OAuth2 server implementation.

Our configuration ultimately looked conceptually like:

Authorization URL:
https://auth.example.com/oauth/authorize

Token URL:
https://auth.example.com/oauth/token

The GPT receives its own OAuth client:

Client ID
Client Secret
Redirect URI
Grant Types

The important grant types were:

authorization_code
refresh_token

The refresh token is particularly important because you don't want customers authenticating again every time ChatGPT needs to call your API.

Why We Used Two Laravel Applications

This implementation had an additional architectural challenge.

The primary application and OAuth server were separate Laravel codebases.

Think of them as:

main-application

and:

auth-application

The main application contained:

Customer accounts
Business logic
API endpoints
User data
Application permissions
Existing API authentication

The Auth application contained:

Laravel Passport
OAuth clients
Authorization codes
Access tokens
Refresh tokens
OAuth authorization
External identity mapping

There are several reasons you might end up with this architecture.

You might want authentication isolated from the main application.

You may already have a separate authentication service.

You may be modernizing a legacy Laravel application.

You may want several applications to eventually use the same OAuth provider.

Whatever the reason, separating the applications creates an important question:

How does an OAuth user in the Auth application map back to the correct user in the main Laravel application?

That became one of the most important parts of this integration.

The Account Linking Problem

Imagine this situation.

Your primary Laravel application contains:

Main Laravel Application

users
----------------
id = 123

Your OAuth application has its own users table:

Auth Laravel Application

users
----------------
id = 456

ChatGPT receives an OAuth access token associated with:

Auth User 456

But your main application's API needs to know:

Main Application User 123

Those aren't inherently the same identity.

You need a trusted mapping between them.

Conceptually:

Auth User 456
        ↓
account_links
        ↓
Application User 123

A linking table can represent that relationship:

application_account_links

auth_user_id
application_user_id

Then OAuth token introspection can return something conceptually like:

{
    "active": true,
    "linked": true,
    "application_user_id": 123,
    "scopes": [
        "profile",
        "channels.read",
        "posts.read",
        "posts.write"
    ]
}

The main Laravel application can now authenticate the incoming API request as User 123.

This is the bridge between:

ChatGPT OAuth identity

and:

Your actual Laravel customer

Never Trust a Browser-Supplied User ID

This part is critical.

You should never build account linking like this:

/connect?user_id=123

and blindly trust that ID.

An attacker could simply change it to:

/connect?user_id=124

Instead, the main Laravel application should cryptographically assert the identity.

We accomplished this with a short-lived signed handoff.

Signed Laravel-to-Laravel Account Handoff

The main application generates a short-lived signed token containing claims such as:

{
    "iss": "example.com",
    "sub": "123",
    "aud": "auth.example.com",
    "iat": 1787540000,
    "exp": 1787540300,
    "jti": "unique-random-value"
}

The important claim is:

sub

That represents the canonical user ID from the main application.

The token is signed using RSA SHA-256:

RS256

The architecture becomes:

Main Laravel Application

Private Key
    ↓
Sign handoff token
    ↓

Auth Laravel Application

Public Key
    ↓
Verify signature

The private signing key remains with the application generating the identity assertion.

The Auth application only needs the public key to verify it.

This gives the Auth application cryptographic proof that:

The main application says this request belongs to User 123.

That's considerably safer than trusting browser-supplied identifiers.

Validate More Than the Signature

Verifying the RSA signature is necessary.

It isn't sufficient.

The Auth application should validate claims such as:

alg
kid
iss
aud
iat
exp
sub
jti

For example:

alg = RS256
issuer = expected application
audience = expected Auth service
expiration = still valid
subject = valid canonical user ID
jti = unique

Do not allow:

alg = none

Do not silently accept an unexpected algorithm.

Do not accept expired handoffs.

Do not trust the subject until after signature verification.

The point of the handoff is to create a small, explicit trust boundary between the two Laravel applications.

Prevent Replay Attacks

A valid signed handoff should generally be redeemable only once.

That's why we included:

jti

The Auth application records each redeemed JTI.

For example:

handoff_redemptions

id
jti
application_user_id
redeemed_by_auth_user_id
redeemed_at

The database should enforce uniqueness on:

jti

Now, if somebody attempts to reuse the exact same handoff, Auth can reject it.

This provides replay protection even if somebody somehow obtains a previously valid handoff URL.

The User Shouldn't Know You Have Two Laravel Applications

Our initial implementation exposed an interesting UX problem.

The Auth application behaved like a normal standalone Laravel application.

A user arriving without an Auth session would see:

Login

Technically, that made sense.

From a product perspective, it didn't.

The customer already has an account in the main application.

Why should they create another account and another password just because we decided to use a separate OAuth service internally?

They shouldn't.

The better experience is:

User logs into main Laravel application
        ↓
Connect ChatGPT
        ↓
Main application creates signed handoff
        ↓
Auth verifies handoff
        ↓
Auth resolves or provisions internal identity
        ↓
Account mapping created
        ↓
OAuth authorization continues

The Auth user becomes an implementation detail.

The customer doesn't need to know it exists.

This is an important lesson when building authentication systems.

There is a difference between:

technically correct authentication

and:

good authentication UX.

Automatically Provisioning the Internal OAuth User

If your OAuth server requires its own local user record, you can automatically provision that internal identity after verifying the signed handoff.

Conceptually:

$link = AccountLink::where(
    'application_user_id',
    $verifiedSubject
)->first();

if ($link) {
    $authUser = $link->authUser;
} else {
    $authUser = createInternalAuthUser();

    AccountLink::create([
        'auth_user_id' => $authUser->id,
        'application_user_id' => $verifiedSubject,
    ]);
}

The actual implementation should be transactional and enforce uniqueness.

The important idea is that the user doesn't have to manually register with your OAuth service.

Their identity has already been established by the trusted main application.

OAuth Scopes Are Worth Doing Properly

Don't give the GPT unlimited API access.

Use OAuth scopes.

For example:

profile
channels.read
posts.read
posts.write

Your Laravel API routes can then require specific scopes.

Conceptually:

Route::get('/connected-channels', ...)
    ->middleware('external-scope:channels.read');

Publishing endpoints might require:

posts.write

Reading existing posts might require:

posts.read

This gives you a clean permission boundary.

If you later introduce:

analytics.read
billing.read
account.write

those capabilities can remain unavailable unless explicitly authorized.

This is especially important with AI integrations because you should expose only the capabilities the AI client actually needs.

Your Existing Laravel API Doesn't Have to Be Replaced

Our main application already had its own API authentication.

We didn't want ChatGPT OAuth support to break or replace existing API clients.

Instead, the API middleware could support multiple authentication paths.

Conceptually:

Incoming API Request
        ↓
Existing API key?
        ↓ yes
Authenticate normally

        ↓ no

External OAuth bearer token?
        ↓
Ask Auth application to introspect token
        ↓
Resolve application user
        ↓
Apply OAuth scopes
        ↓
Continue request

This allows existing integrations to continue working while ChatGPT uses OAuth.

That's an important architectural principle:

Add AI integration capabilities without unnecessarily rewriting working application infrastructure.

At Custom PHP Design, this is how we approach Laravel modernization projects: integrate with what already works instead of automatically assuming the entire application needs to be rebuilt.

Learn more:

Custom PHP Design

Token Introspection Between Laravel Applications

The main application should not directly query Passport's database.

That would tightly couple the two applications.

Instead:

Main Application
       ↓
Server-to-server request
       ↓
Auth Application
       ↓
Passport token validation
       ↓
Account mapping
       ↓
Introspection response

The request should use a server-to-server secret.

For example:

X-Application-Auth-Secret

The browser never sees this value.

ChatGPT never sees this value.

It exists strictly between your servers.

The main application sends the OAuth access token to the Auth service for validation.

Conceptually:

{
    "token": "oauth-access-token"
}

The Auth application returns something similar to:

{
    "active": true,
    "linked": true,
    "application_user_id": 123,
    "scopes": [
        "channels.read",
        "posts.read",
        "posts.write"
    ]
}

Now your normal Laravel middleware can resolve:

User::findOrFail($applicationUserId);

and continue processing the API request.

Don't Put Server Secrets in the Browser

This deserves its own section.

Your introspection secret should never appear in:

JavaScript
HTML
Blade data attributes
localStorage
sessionStorage
query strings
frontend API calls

The communication should be:

ChatGPT
    ↓ bearer token
Main Laravel API
    ↓ private server-to-server request
Auth Laravel Application

Not:

Browser
    ↓ secret
Auth Application

Keep internal authentication internal.

A Tiny Header Name Cost Us Debugging Time

One of the bugs we encountered was painfully simple.

One Laravel application sent a header similar to:

X-Application-Introspection-Secret

while the Auth application expected something similar to:

X-Application-Auth-Secret

The result?

401 Unauthorized

Everything else was correct:

The bearer token existed
OAuth worked
The account was linked
The API route existed
The scope existed
The GPT was making the request

But the server-to-server authentication failed before token introspection could happen.

The lesson:

Standardize internal authentication headers and configuration names.

Better yet, encapsulate server-to-server communication inside a service class instead of scattering raw HTTP requests throughout your Laravel application.

Safe Diagnostic Logging Is Extremely Helpful

When debugging OAuth, logging everything is tempting.

Don't.

Never log:

access_token
refresh_token
client_secret
private keys
shared secrets
authorization codes
signed handoff tokens

Instead, log state.

For example:

{
    "external_introspection_attempted": "yes",
    "introspection_http_status": 200,
    "introspection_active": "yes",
    "introspection_linked": "yes",
    "resolved_application_user_id": 123,
    "scopes": [
        "channels.read"
    ],
    "auth_result": "external_oauth"
}

That tells you almost everything you need without leaking credentials.

During development, this was invaluable.

We could watch the request move through:

ChatGPT
→ Auth
→ Main API
→ Introspection
→ User resolution
→ Scope validation
→ Controller

When something failed, we knew exactly which boundary was failing.

File Permissions Can Break OAuth Too

Another production issue had almost nothing to do with OAuth protocol logic.

Laravel Passport's RSA keys had incorrect filesystem permissions after deployment.

Instead of:

a Passport key ended up with:

The OAuth library rejected it.

The result appeared upstream as:

500 Internal Server Error

The fix was straightforward:

sudo chown www-data:www-data storage/oauth-private.key
sudo chown www-data:www-data storage/oauth-public.key

sudo chmod 600 storage/oauth-private.key
sudo chmod 600 storage/oauth-public.key

But fixing it manually isn't enough.

Your deployment process should enforce it.

For example:

echo "Setting Laravel runtime permissions..."

sudo chown -R www-data:www-data storage bootstrap/cache
sudo chmod -R ug+rwX storage bootstrap/cache

if [[ -f storage/oauth-private.key ]]; then
    sudo chmod 600 storage/oauth-private.key
fi

if [[ -f storage/oauth-public.key ]]; then
    sudo chmod 600 storage/oauth-public.key
fi

This also helps prevent another classic Laravel production error:

storage/logs/laravel.log: Permission denied

Production automation should leave your application in a known-good state after every deployment.

The GPT Action OAuth Configuration

Once the backend architecture was ready, the GPT Action itself needed OAuth configuration.

Conceptually:

Authentication Type:
OAuth

Client ID:
<passport-client-id>

Client Secret:
<passport-client-secret>

Authorization URL:
https://auth.example.com/oauth/authorize

Token URL:
https://auth.example.com/oauth/token

Scopes:
profile channels.read posts.read posts.write

ChatGPT provides a callback URL.

That callback must match the redirect URI registered with your OAuth server.

Exactly.

Not approximately.

Not "same domain."

Not "close enough."

Exactly.

If ChatGPT gives you:

https://chat.openai.com/aip/g-example/oauth/callback

then your Passport OAuth client needs that callback.

Be Careful When Recreating or Editing Your GPT

During development, callback URLs can become a source of confusion.

If the callback associated with the GPT changes, your Passport client can still contain the old redirect URI.

Then ChatGPT sends:

redirect_uri = NEW_CALLBACK

while Passport expects:

OLD_CALLBACK

OAuth fails.

Instead of constantly creating new clients and secrets, we built tooling to safely update the existing Passport client's redirect URI while preserving:

Client ID
Secret
Grant Types
Name
State

That proved extremely useful during development.

The broader lesson is:

Build diagnostic and administrative tools around OAuth instead of manually editing database rows.

Passport Schemas Change Between Versions

Another lesson: don't assume examples written for an older Laravel Passport version match your installation.

For example, older examples may reference:

redirect

while newer Passport versions can use fields such as:

redirect_uris
grant_types

If you run something like:

Laravel\Passport\Client::all([
    'id',
    'name',
    'redirect',
    'revoked'
]);

against a schema that no longer contains redirect, you'll get a database error.

Always inspect the actual Passport version and schema you're using.

Don't blindly copy an OAuth tutorial written several major versions ago.

Build Diagnostic Artisan Commands

One of the best things we did during this project was build small Artisan commands specifically for OAuth diagnostics.

For example, a command could inspect:

Client ID
Client name
Redirect URIs
Grant types
Revoked state
Client type
Secret storage
Exact redirect match

You can even securely prompt for the client secret and verify whether it matches the stored hash without printing either value.

Conceptually:

php artisan oauth:inspect-clients \
    'CLIENT_ID' \
    --redirect-uri='EXACT_CALLBACK' \
    --verify-secret

Output might look like:

State: active
Client type: confidential
Secret storage: hashed
Grant types: authorization_code, refresh_token
Exact redirect match: yes
Submitted secret matches: yes

That's dramatically better than guessing.

Your OpenAPI Schema Is the GPT's Map

Authentication gets the GPT through the front door.

Your OpenAPI specification tells it what it can actually do.

Suppose your application exposes:

/api/v1/connected-channels:
  get:
    operationId: getConnectedChannels

And:

/api/v1/posts:
  post:
    operationId: createPost

The descriptions matter.

Good:

summary: Get the authenticated user's connected social media channels

Less useful:

summary: Get channels

The model needs enough semantic information to understand when an operation applies.

Operation IDs should also be descriptive:

getConnectedChannels
createSocialPost
scheduleSocialPost
getScheduledPosts

rather than:

get1
post2
action3

Treat your OpenAPI specification as part API contract and part AI interface.

Confirmation Before Destructive or External Actions

AI-driven API access raises another UX consideration.

Some operations should happen immediately.

For example:

Show me my connected channels.

That's read-only.

But:

Publish this to Facebook and Instagram.

has an external side effect.

For workflows like publishing, deleting, sending, purchasing, or modifying important records, design your Action and GPT instructions so the user has an opportunity to confirm what will happen.

A good interaction might be:

User:
Create a post about our product launch for Facebook and Instagram.

GPT:
Here's the proposed post:

...

Would you like me to publish this to Facebook and Instagram?

User:
Yes.

GPT:
→ API Action
→ publish

This is better than making every conversational request immediately destructive.

Test the Entire Chain, Not Just OAuth

An OAuth token successfully being issued does not mean your integration works.

We tested the entire path:

ChatGPT
    ↓
Authorization request
    ↓
Laravel Passport
    ↓
Authorization code
    ↓
Token exchange
    ↓
Access token
    ↓
GPT Action request
    ↓
Main Laravel API
    ↓
External token introspection
    ↓
Account mapping
    ↓
Scope validation
    ↓
Correct application user
    ↓
Actual application data

The moment that mattered wasn't when Passport issued a token.

It was when we could ask:

Show me my connected social channels.

and receive the channels belonging to the correct application user.

That proved the architecture end-to-end.

Test With More Than One User

Before calling an OAuth integration production-ready, test user isolation.

Create or use at least two application users.

Then verify:

User A
→ OAuth
→ User A's resources

and:

User B
→ OAuth
→ User B's resources

Never:

User B
→ OAuth
→ User A's resources

Also test:

Token refresh
Expired tokens
Revoked tokens
Missing scopes
Invalid scopes
Missing account mapping
Conflicting account mapping
Replayed handoff
Auth service unavailable
Invalid server-to-server secret
Invalid OAuth client secret
Incorrect redirect URI

Happy-path testing is not enough for authentication systems.

The ChatGPT Account Limitation You Need to Know About

Now for the frustrating part.

You can build the entire integration correctly and still discover that you cannot distribute your GPT the way you expected.

As of 2026, OpenAI's documentation states that new GPT creation and publishing are not available on personal ChatGPT accounts, including:

Free
Go
Plus
Pro

Existing GPTs can remain available to their owners and can still be edited when the applicable plan and permissions allow it.

However, creating and publishing GPTs is currently available through eligible managed workspaces such as:

Business
Enterprise
Edu

subject to workspace permissions.

This is important because upgrading from ChatGPT Plus to the much more expensive personal ChatGPT Pro plan does not necessarily solve the GPT publishing problem.

Pro is still a personal account.

If your goal is to create a GPT that customers can access, you need to evaluate the current Business/Enterprise/Edu workspace requirements before investing significant development time.

Why This Matters for Independent Developers and SaaS Companies

This creates an interesting situation for solo developers and small SaaS companies.

You may be able to:

Build the GPT
Configure the Action
Implement OAuth
Test the API
Use the GPT privately
Prove the entire architecture

but still need an eligible managed ChatGPT workspace before you can distribute that GPT to customers.

That doesn't make the development work useless.

Far from it.

Your OAuth-enabled API can potentially support many other clients.

And your private GPT can serve as a beta environment while you validate whether customers actually want conversational access to your application.

That's exactly how I would approach it.

Prove demand before adding another recurring expense.

A Private GPT Can Still Be a Valuable Beta

If you already have an existing GPT on a personal account, private testing can be extremely useful.

You can validate:

OAuth
Account linking
API authentication
Scopes
Token refresh
OpenAPI operations
Prompt behavior
Error handling
User confirmation
API response design

before making the integration broadly available.

That gives you a working prototype.

If customers later start asking:

Can I control this from ChatGPT?

you already know the backend architecture works.

At that point, moving the GPT into an eligible managed workspace becomes a business decision rather than an experiment.

GPT Actions Are Really API Product Development

One of my biggest takeaways from this project is that GPT Actions aren't primarily about prompt engineering.

The hard part isn't writing:

You are a helpful social media assistant.

The hard part is everything behind it:

Authentication
Authorization
OAuth
Account linking
Scopes
API design
OpenAPI
Security boundaries
Error handling
Deployment
User isolation
Token lifecycle
Observability

In other words:

Building a serious GPT Action is backend application development.

If you already have a well-designed Laravel API, you're in a strong position.

If you don't have an API yet, adding GPT Actions may expose architectural work that needs to happen first.

Laravel Is a Great Fit for GPT Action Integrations

Laravel gives you many of the building blocks needed for this kind of project:

Routing
Middleware
Authentication
Authorization
Laravel Passport
HTTP client
Validation
Service containers
Queues
Events
Logging
Database transactions
Testing
Rate limiting
Configuration management

A typical architecture can remain very Laravel-native.

For example:

GPT Action
    ↓
Laravel API Route
    ↓
Authentication Middleware
    ↓
Scope Middleware
    ↓
Controller
    ↓
Service
    ↓
Application Logic

You don't need to throw away your existing Laravel architecture just because AI is involved.

You Probably Don't Need to Rewrite Your Laravel Application for AI

This is another area where companies can easily overspend.

Adding AI functionality doesn't necessarily mean rewriting your application around AI.

If you already have a working Laravel application, you may only need:

API endpoints
OAuth
OpenAPI schema
Identity mapping
AI-specific service layer
Additional authorization

Your existing:

Models
Services
Jobs
Queues
Database
Business logic

can often remain exactly where they are.

The AI becomes another interface into the application.

That's a much more practical way to modernize an existing system.

Need GPT Actions Added to Your Laravel Application?

If you have an existing Laravel or custom PHP application and you're wondering:

Can ChatGPT securely interact with my application?

The answer may very well be yes.

At Custom PHP Design, we work with custom PHP and Laravel applications and can help design and implement integrations involving:

ChatGPT GPT Actions
OpenAI integrations
Laravel APIs
OpenAPI specifications
OAuth 2.0
Laravel Passport
API authentication
Account linking
External SaaS integrations
AI-assisted workflows
Existing application modernization
AWS deployments
CI/CD
Laravel architecture

Whether you have a modern Laravel application or a custom PHP system that's been evolving for years, you don't necessarily need to rebuild everything to take advantage of AI.

Sometimes the right solution is to build a secure bridge between what you already have and what AI can now provide.

👉 Learn more about Custom PHP Design:

Custom PHP Design

If you're trying to determine whether GPT Actions can be integrated into your existing Laravel application, Custom PHP Design can help evaluate the architecture and build the integration.

Final Architecture

After working through the authentication, account linking, API middleware, introspection, and deployment issues, the architecture ultimately looked like this:

┌─────────────────────────┐
│        ChatGPT          │
│       Custom GPT        │
└────────────┬────────────┘
             │
             │ OAuth Authorization
             ▼
┌─────────────────────────┐
│   Laravel Auth Service  │
│                         │
│   Laravel Passport      │
│   OAuth Clients         │
│   Access Tokens         │
│   Refresh Tokens        │
└────────────┬────────────┘
             │
             │ Account Mapping
             ▼
┌─────────────────────────┐
│  Application Identity   │
│                         │
│ Auth User ↔ App User    │
└────────────┬────────────┘
             │
             │ Token Introspection
             ▼
┌─────────────────────────┐
│ Main Laravel Application│
│                         │
│ API Authentication      │
│ OAuth Scope Validation  │
│ Existing Business Logic │
└────────────┬────────────┘
             │
             ▼
┌─────────────────────────┐
│      Customer Data      │
└─────────────────────────┘

And from the user's perspective?

It can be as simple as:

Show me my connected social channels.

That's the part users see.

Everything else is our job as developers.

Final Thoughts

GPT Actions open up some genuinely interesting possibilities for existing Laravel applications.

But don't mistake them for a simple prompt-engineering exercise.

Once a GPT needs to securely access private customer data or perform actions on behalf of a user, you're dealing with traditional application engineering concerns:

Identity
Authentication
Authorization
OAuth
API security
User isolation
Scopes
Token management
Infrastructure
Deployment
Observability

The good news is that Laravel is extremely well suited to solving those problems.

And once the foundation exists, the conversational layer can be surprisingly powerful.

A user doesn't necessarily need to know which API endpoint to call.

They don't need to know your JSON structure.

They don't need to know your controller names.

They can simply explain what they want.

ChatGPT determines the appropriate Action.

Your Laravel application remains responsible for determining whether that action is authorized and executing it safely.

That's the architecture I expect we'll see more of as AI becomes another interface for traditional web applications.

Want to Add ChatGPT Actions to Laravel?

If you have a Laravel or custom PHP application and want to explore secure ChatGPT integration, OAuth, APIs, or AI-driven workflows, visit:

Custom PHP Design

https://www.customphpdesign.com/

We specialize in custom PHP and Laravel development, including integrations that connect existing applications with modern APIs, cloud infrastructure, and AI platforms.

Instead of replacing years of existing development, we can help determine how to extend what you already have.

Laravel + APIs + OAuth + GPT Actions can turn an existing application into something your users can interact with conversationally.

And that's a pretty exciting direction for custom web development.

This article is based on lessons learned while implementing and debugging a real Laravel-to-ChatGPT OAuth integration. Always review the latest OpenAI GPT and Actions documentation before implementing your own integration, as account availability, publishing requirements, OAuth behavior, and platform features can change.

What It Really Takes to Get YouTube Live and TikTok Publishing Approved

Robert Saylor — Thu, 13 Aug 2026 23:16:07 +0000

Building a social media integration is one thing.

Getting the social network to actually approve it for production is another.

Over the past several months, I have been building VidSyndicate, a social media publishing and video distribution platform. One of the goals behind the project is to give businesses a single application for managing content across networks such as Facebook, Instagram, LinkedIn, YouTube, Pinterest, TikTok, and others.

From a development standpoint, connecting an API is often the easy part.

The difficult part can be getting through the platform's review process.

Recently, we reached two major milestones:

YouTube Live was approved
TikTok's draft/inbox publishing workflow was approved

Neither approval was a simple "submit the app and wait" process.

There were multiple rounds of development, documentation, demonstrations, policy changes, scope explanations, branding updates, and reviewer feedback before we got there.

As the developer behind both Custom PHP Design and VidSyndicate, the experience reinforced something I have been seeing for years:

Social media API integration requires more than knowing how to make an HTTP request.

It requires understanding the platform, OAuth, permissions, security, application architecture, compliance, and increasingly, how to communicate your implementation to an auditor.

Building YouTube Live Into VidSyndicate

The YouTube integration started with normal video publishing, but I wanted VidSyndicate to go considerably further.

I wanted users to be able to create and manage a YouTube livestream directly through VidSyndicate.

That meant integrating with Google's OAuth system, the YouTube Data API, and YouTube's live streaming functionality.

The completed workflow allows VidSyndicate to handle much of the livestream lifecycle from inside the application.

That includes creating the broadcast, creating and connecting the stream, monitoring its status, displaying live information, and ending the broadcast.

Behind the scenes, the actual streaming infrastructure was another engineering project entirely.

VidSyndicate uses cloud infrastructure and FFmpeg-based processing to handle the video stream. I eventually moved toward isolated AWS ECS tasks for livestream workloads rather than treating streaming like a normal web request.

That part was challenging.

But getting the OAuth permissions approved was a different kind of challenge.

The Code Worked Before the Review Was Finished

This is something businesses need to understand when developing social media integrations.

Working code does not automatically mean you have a production-ready integration.

You can successfully authenticate against an API.

You can successfully create a broadcast.

You can successfully upload a video.

You can successfully receive data.

And your application can still fail the platform review.

Google needed to understand exactly why VidSyndicate requested its YouTube permissions and how those permissions were being used.

For youtube.upload, the purpose is fairly straightforward: users authorize VidSyndicate to upload videos they have selected.

The live streaming functionality requires broader capabilities.

VidSyndicate needs to create and manage broadcasts and streams, connect them, monitor their state, interact with live functionality, and manage the broadcast lifecycle.

Explaining that clearly became part of getting the application approved.

Then Comes the Screencast

A social platform reviewer doesn't have the same context the developer has.

I had spent months working on VidSyndicate. I knew exactly what every button did and why every API request existed.

The reviewer doesn't.

That means the demonstration itself becomes part of the engineering process.

For the YouTube review, we had to make sure the demonstration clearly showed the authorization process and the actual functionality associated with the requested permissions.

The review material walked through the process from beginning to end:

Connect the YouTube account.
Display the requested Google/YouTube permissions.
Create a livestream.
Start the streaming infrastructure.
Verify the broadcast through YouTube.
Monitor the live broadcast.
Demonstrate the application's live functionality.
End the stream.

The privacy policy also had to clearly explain how Google and YouTube user data was accessed and used.

Even small details mattered.

At one point, Google's feedback required the OAuth consent experience to make the services being requested clearer. That meant revisiting the consent flow and the supporting demonstration rather than simply saying, "The API works."

Eventually the functionality, branding requirements, privacy disclosures, and requested scopes moved through the verification process.

TikTok Was Its Own Adventure

TikTok presented a completely different review experience.

VidSyndicate supports a TikTok workflow where a video can be sent to TikTok and delivered through TikTok's inbox/draft-style publishing experience.

The user completes the final publishing process inside TikTok.

From an application-design perspective, it is a useful middle ground.

VidSyndicate can prepare and transfer the content while TikTok retains the final publishing interaction.

Getting that functionality approved still required going back and forth through TikTok's review process multiple times.

And this wasn't my first experience dealing with TikTok review.

We had gone through TikTok audit attempts before. Each submission teaches you a little more about what the reviewer expects to see.

Sometimes the Rejection Isn't About Your API Code

One of the TikTok review issues is a good example of why social integration work can become frustrating.

The underlying integration could work correctly while something seemingly minor prevented approval.

Branding was one of those issues.

The application icon needed to properly match the product branding.

That meant making sure the icon, application identity, and website presentation were consistent enough for the reviewer.

From a programmer's perspective, changing an icon has absolutely nothing to do with whether an OAuth callback or publishing API works.

From the platform's perspective, however, identity and branding are part of determining whether users understand which application they are authorizing.

So you fix it.

Then you submit again.

Submit, Wait, Fix, Demonstrate, Repeat

That became a recurring pattern during development:


text
Build the integration
        ↓
Test it
        ↓
Submit for review
        ↓
Wait
        ↓
Receive reviewer feedback
        ↓
Determine what the reviewer actually needs
        ↓
Update the application or documentation
        ↓
Record another demonstration when necessary
        ↓
Resubmit
        ↓
Repeat

Laravel Development Process: From Idea to Production

Robert Saylor — Wed, 12 Aug 2026 09:33:42 +0000

Building a Laravel application involves much more than writing PHP code. A production application needs to solve a real business problem, handle users and data reliably, survive deployments, remain secure, and continue to be maintainable as requirements change.

Laravel provides an excellent foundation for building modern web applications, but the framework is only one part of the development process.

A successful Laravel project typically moves through several stages, from understanding the original business idea to deploying, monitoring, and improving the application in production.

Here is what that process looks like.

1. Start With the Business Problem

Before thinking about controllers, models, databases, or cloud infrastructure, the first step is understanding what the application actually needs to accomplish.

A project might begin with a simple request:

"We need a customer portal."

That's a starting point, but it isn't a specification.

What should customers be able to do?

Create and manage accounts?
Upload documents?
Manage subscriptions?
Make payments?
View reports?
Communicate with employees?
Receive notifications?
Manage multiple users within an organization?

These questions start turning an idea into actual application requirements.

One of the easiest ways for a software project to become unnecessarily expensive is to begin development before the problem has been clearly defined.

Laravel can make development faster, but building the wrong application faster doesn't solve the underlying problem.

2. Define the MVP

Once the requirements become clearer, the next step is determining what belongs in the first release.

I generally separate features into two categories:

What does the application need in order to provide value?

and

What can be added later?

The first category becomes the Minimum Viable Product, or MVP.

For example, a new SaaS application might initially require:

User registration
Authentication
Account management
Subscription billing
The application's primary feature
Basic administration
Email notifications

Features such as advanced analytics, AI integrations, extensive automation, or mobile applications may be valuable, but they don't necessarily need to be part of version one.

Keeping the initial scope focused makes it easier to get a working application into production and start learning from real users.

3. Plan the Laravel Application Architecture

Once the scope is understood, development can move into application architecture.

Laravel provides many of the components needed for modern web applications, including:

Routing
Middleware
Authentication
Authorization
Eloquent ORM
Queues
Events
Notifications
Scheduled tasks
Caching
API resources
Testing tools

The important architectural question isn't whether Laravel can perform these tasks.

It's deciding how they should work together.

A relatively small application may work perfectly with traditional Laravel controllers, models, services, jobs, and Blade templates.

A larger application may need more separation between business logic and the HTTP layer.

The goal shouldn't be to make the architecture as complicated as possible.

The goal is to create an application structure that developers can understand and maintain as the software grows.

4. Design the Database Carefully

Database design is one of the most important parts of custom application development.

Laravel migrations make database changes easy to manage, while Eloquent makes interacting with relational data convenient.

But neither eliminates the need for good database design.

Before building features, think about:

Relationships between entities
Foreign keys
Indexes
Data types
Unique constraints
Historical data
Soft deletes
Data retention
Expected query patterns

Poor database decisions can be relatively invisible during early development and become painful once an application contains millions of records.

Changing a database schema with 500 test records is easy.

Changing it safely after the application has accumulated years of production data can be much more complicated.

5. Build the Core Laravel Application

With the architecture and data model established, development can move into the application's primary features.

Laravel's conventions help developers move quickly.

A typical feature might involve:

Creating or updating a migration
Creating the Eloquent model
Defining relationships
Creating routes
Adding controllers or actions
Implementing authorization
Building validation
Adding the user interface or API
Writing tests

More complex features may also involve Laravel jobs, queues, events, notifications, commands, or scheduled tasks.

Keeping business logic organized becomes increasingly important as the application grows.

A controller containing hundreds of lines of unrelated business logic may work today, but it becomes difficult to maintain later.

6. Add APIs and Third-Party Integrations

Most modern applications don't operate in isolation.

A Laravel application might integrate with:

Payment providers
Email services
Social platforms
CRM systems
Accounting software
Cloud storage
AI APIs
Analytics platforms
Internal business systems

Laravel provides excellent tools for building APIs and communicating with external services.

The harder part is designing integrations to handle failure.

External APIs can time out.

Rate limits can be reached.

Credentials can expire.

Providers can return unexpected responses.

A production integration should account for those possibilities rather than assuming every API request will succeed.

Queues and retry mechanisms can be particularly useful when an external operation doesn't need to complete during the user's original web request.

7. Use Queues for Background Processing

Not every operation should happen while a user waits for a page to load.

Laravel queues are useful for operations such as:

Sending emails
Processing uploaded files
Generating reports
Calling external APIs
Importing large datasets
Processing videos
Sending notifications
Running AI operations

Instead of forcing the user to wait, the application can dispatch a job and allow a queue worker to process it separately.

This can significantly improve application responsiveness and reliability.

It also introduces another production consideration: queue workers need to be deployed, monitored, restarted when necessary, and scaled as workload increases.

8. Use Git From the Beginning

Source control shouldn't be something added shortly before deployment.

Git should be part of the development workflow from the beginning.

A typical workflow might include:

Feature branches
Pull or merge requests
Code review
Automated testing
Deployment from a controlled branch

Even when one developer is building the application, source control provides a history of changes and a safer way to manage releases.

Once multiple developers become involved, a consistent Git workflow becomes even more important.

9. Test Before Production

Laravel includes strong support for automated testing.

Tests can verify things such as:

Authentication
Authorization
API responses
Database operations
Validation
Business rules
User workflows

Not every application requires thousands of tests, but critical business functionality should have automated protection.

Imagine an application where customers purchase subscriptions.

A test could verify that:

A customer selects a plan.
The payment provider confirms the transaction.
The subscription is created.
The correct permissions are assigned.
The customer receives confirmation.

That test becomes especially valuable months later when another feature changes part of the billing system.

10. Prepare the Application for Production

Development and production environments are different.

Before deployment, several areas need attention.

These may include:

Environment variables
Production database configuration
Cache configuration
Queue configuration
Session storage
File storage
HTTPS
Logging
Error handling
Backups
Email configuration
Security settings

Laravel's configuration system makes managing environments straightforward, but production credentials should never be stored directly in source control.

Secrets should be managed securely through the deployment platform or cloud infrastructure.

11. Build CI/CD Instead of Deploying Manually

Manual deployments may work initially, but they become risky as applications grow.

A CI/CD pipeline can automate much of the release process.

A Laravel deployment pipeline might:

Retrieve the application source
Install Composer dependencies
Install and build frontend dependencies
Run automated tests
Build a Docker image
Push the image to a container registry
Deploy the new application version
Run database migrations
Restart workers
Verify application health

Automation makes deployments more repeatable.

If deploying an application requires someone to remember 15 commands in exactly the correct order, eventually something will be missed.

The deployment process should be part of the application's architecture rather than an afterthought.

12. Deploy Laravel to Production Infrastructure

Laravel can run in many environments.

For smaller applications, a traditional Linux server may be perfectly appropriate.

Larger applications may use cloud infrastructure with services for:

Compute
Load balancing
Managed databases
Object storage
Container orchestration
Caching
Monitoring
Secrets management

AWS is one option frequently used for production Laravel applications.

Depending on the application's requirements, an AWS architecture might include services such as EC2, ECS, ECR, RDS, S3, CloudWatch, Route 53, and load balancers.

Infrastructure should match the application's actual needs.

Not every Laravel application requires Kubernetes or an elaborate microservice architecture.

Good architecture is often about choosing the simplest solution that can reliably meet the requirements.

13. Monitor What Happens After Deployment

Getting the application into production isn't the end of development.

It's the beginning of operating the application.

Production monitoring should help answer questions such as:

Is the application available?
Are requests becoming slower?
Are errors increasing?
Are queue jobs failing?
Is the database overloaded?
Is storage approaching capacity?
Did the latest deployment introduce a problem?

Application logs, infrastructure metrics, error tracking, and alerts provide visibility into what users are actually experiencing.

Without monitoring, teams often discover problems when customers report them.

14. Plan for Backups and Recovery

Backups are easy to ignore until they're needed.

A production application should have a documented strategy for protecting important data.

That may include:

Automated database backups
Object storage protection
Backup retention policies
Database snapshots
Recovery procedures

Having backups isn't enough.

You also need to know that they can actually be restored.

A backup strategy that has never been tested is still a risk.

15. Continue Improving the Application

Production applications rarely stay unchanged.

Users request features.

Business processes change.

External APIs change.

Security updates become available.

Traffic increases.

New integrations become necessary.

This is why maintainability matters from the beginning.

An application that was rushed into production with no architecture, testing, deployment automation, or documentation becomes increasingly expensive to change.

A well-structured Laravel application provides a much better foundation for continued development.

Laravel Development Is More Than Writing PHP

Laravel makes building sophisticated PHP applications significantly easier, but the framework is only one part of delivering production software.

A complete Laravel development process includes:

Idea → Requirements → Architecture → Database Design → Development → Testing → CI/CD → Infrastructure → Deployment → Monitoring → Maintenance

Each stage affects the stages that follow.

Good requirements make architecture easier.

Good architecture makes development easier.

Testing makes deployments safer.

Automation makes releases repeatable.

Monitoring makes production problems easier to identify.

And maintainable code makes the next feature easier to build.

That's ultimately what separates simply building a Laravel application from building a Laravel application that can reliably support a real business.

I work extensively with Laravel, custom PHP applications, AWS infrastructure, APIs, CI/CD, and application modernization through Custom PHP Design.

If you're interested in more articles about Laravel development and building production PHP applications, you can also find them on the Custom PHP Design blog.

About the Author

Robert Saylor is a PHP/Laravel developer and DevOps engineer with experience building, modernizing, deploying, and operating production web applications. He writes about Laravel development, custom PHP applications, AWS, DevOps, CI/CD, SaaS development, and practical software architecture at Custom PHP Design.

Robert is also the author of Vibe Coding: The Modern Developer, a practical guide to building production-ready applications with modern development workflows, Laravel, Git, CI/CD, and AWS.

The Long Road to Meta App Approval: Why Building Real SaaS Products Isn't Easy

Robert Saylor — Thu, 06 Aug 2026 10:26:44 +0000

When people look at a polished SaaS application, it's easy to assume it was built over a weekend.

A login page.

A dashboard.

A few API integrations.

Simple, right?

Not even close.

Over the past several months I've been building VidSyndicate, a platform that allows creators to upload a video once and publish it across multiple social media platforms.

The coding was only half the challenge.

The real battle was getting approved by Meta.

The Approval Process Is Much More Than Writing Code

Connecting to Facebook and Instagram isn't as simple as requesting an API key.

Meta requires developers to prove that their application is legitimate before granting access to publishing features.

That means documenting:

Every permission requested
Every API call
Exactly how user data is used
Privacy policy updates
Terms of Service
Screen recordings
End-to-end demonstrations
Production-ready user flows

Every permission has to be justified.

Every feature has to work exactly as described.

Small Mistakes Mean Rejection

During development I had several review cycles that didn't go as planned.

Sometimes it was because Meta wanted additional clarification.

Other times it was because a workflow wasn't demonstrated exactly the way reviewers expected.

The APIs worked.

The software worked.

But platform reviews have their own requirements that go far beyond software development.

You have to think like both a developer and a compliance officer.

The Final Result

After another review cycle, the application was finally approved.

The latest approval included:

✅ business_management
✅ pages_manage_posts
✅ pages_show_list
✅ pages_read_engagement
✅ instagram_basic
✅ instagram_business_basic
✅ instagram_content_publish
✅ instagram_manage_messages
✅ instagram_business_manage_messages

This means VidSyndicate can now publish directly to Facebook Pages and Instagram Business accounts through Meta's official APIs.

That approval represents months of development, testing, documentation, and revisions.

The Software Is Only Part of the Product

One lesson that every SaaS founder eventually learns is this:

Writing the application is often the easiest part.

Building a production-ready platform means dealing with:

OAuth security
Token management
API rate limits
Permission reviews
Privacy compliance
Error handling
Infrastructure
Monitoring
Documentation
User experience

None of these features are flashy, but they're what transform a side project into a product businesses can trust.

Experience Matters

This experience reinforced something I've believed for years.

There's a significant difference between writing code that works and building software that's ready for production.

Production software must handle:

Third-party platform requirements
Security best practices
Long-term maintainability
Infrastructure automation
Compliance reviews
Unexpected edge cases

These are the same engineering principles I use every day through Custom PHP Design, where I build custom PHP, Laravel, AWS, and DevOps solutions for businesses. Developing client software over the years has provided the experience needed to tackle complex platform integrations like Meta's review process, while building VidSyndicate has allowed me to apply those same production-ready practices to a real-world SaaS platform.

What's Next for VidSyndicate

With Meta approval complete, development can now focus on building new features instead of waiting on platform access.

Current supported platforms include:

YouTube
Facebook
Instagram
TikTok
LinkedIn
Pinterest
Bluesky
Mastodon
X

I'm also continuing work on live streaming, AI-assisted publishing, and additional automation tools to help creators distribute content more efficiently from a single dashboard.

Final Thoughts

One of the biggest misconceptions in software development is that success comes from writing clever code.

In reality, successful products are built by solving hundreds of small problems that users never see.

Meta approval wasn't just another checkbox.

It was proof that VidSyndicate meets the standards required to integrate with one of the largest social platforms in the world.

Whether I'm building custom software for clients through Custom PHP Design or developing VidSyndicate, the goal is the same: build secure, scalable, production-ready software that people can rely on.

Sometimes the hardest part of software development isn't writing the code.

It's proving that your software is ready for the real world.

Building Software That Solves Real Problems with Laravel, AI, and AWS

Robert Saylor — Sat, 01 Aug 2026 19:47:08 +0000

When people think about software development, they often focus on the technology stack. At Custom PHP Design, we believe technology is only part of the equation. The real goal is solving business problems with software that is reliable, scalable, and built to last.

Using Laravel, PHP, AWS, DevOps, and AI-assisted development, we've built applications that help creators, authors, businesses, and researchers work more efficiently. Here are a few of the projects we've been working on.

VidSyndicate

https://vidsyndicate.com

One of our newest projects is VidSyndicate, a social media publishing platform built for creators, businesses, and marketing teams.

Instead of manually uploading the same video or post to multiple social networks, users can prepare content once, customize it for each platform, and publish everywhere from a single dashboard.

Current areas of development include:

AI-assisted content generation
Cross-platform scheduling
Video publishing workflows
Social media automation
Creator productivity tools

Our goal is simple: help creators spend more time creating and less time copying and pasting content.

CoverStudioAI

https://coverstudioai.com

Creating professional book covers shouldn't require expensive desktop software or years of graphic design experience.

That's why we built CoverStudioAI, a browser-based design platform focused on Amazon KDP authors.

The platform allows authors to create paperback, hardcover, and Kindle covers that meet Amazon's publishing specifications. AI-assisted design tools help speed up the creative process while giving users complete control over the final design.

Whether you're publishing your first book or your hundredth, CoverStudioAI aims to make professional cover design accessible to everyone.

Historical Text Archive

https://historicaltextarchive.org

Not every project we build is a SaaS platform.

The Historical Text Archive is one of our longest-running projects and preserves thousands of historical articles, photographs, and primary source documents from around the world.

We've modernized the platform with Laravel, improved search capabilities, implemented structured SEO data, enhanced performance, and continue expanding the archive so historical research remains freely available to students, educators, and history enthusiasts.

Technology can preserve knowledge just as effectively as it creates new experiences.

Vibe Coding as the Modern Developer

https://www.customphpdesign.com/book/vibe-coding-as-the-modern-developer

As AI continues to transform software development, we've documented many of the workflows and techniques we've adopted in Vibe Coding as the Modern Developer.

Rather than focusing only on prompts, the book explores how experienced developers can combine AI with Laravel, Git, CI/CD, AWS, DevOps, testing, and sound software architecture to build production-ready applications. AI is a powerful development partner, but engineering experience is still what turns ideas into reliable software.

About Custom PHP Design

https://www.customphpdesign.com

Custom PHP Design specializes in building custom Laravel applications, SaaS platforms, APIs, cloud infrastructure, AI-assisted development workflows, and legacy application modernization.

Every project we create starts with the same question:

How can software make someone's job easier?

Whether we're helping creators automate social media publishing, enabling authors to design professional book covers, or preserving historical knowledge for future generations, our mission remains the same—building software that solves real-world problems.

If you're interested in Laravel, PHP, AWS, AI-assisted development, or modern software engineering, we'd love to connect with you.

I Built a Social Media Publishing Tool Because I Was Tired of Copy/Paste

Robert Saylor — Sat, 01 Aug 2026 10:19:22 +0000

If you've ever launched a side project, SaaS, YouTube channel, or blog, you've probably experienced this workflow:

Write a post.
Publish it to X.
Open LinkedIn.
Rewrite it.
Open Facebook.
Change the formatting.
Upload it to Bluesky.
Then Mastodon.
Then Pinterest.
Then YouTube.

You spend more time publishing than creating.

As a full-time DevOps engineer and indie developer, I found myself spending hours every week repeating the same tasks. Every platform has different requirements, different APIs, different formatting, different media limits, and different audiences. The actual content wasn't the hard part—it was everything after clicking Publish.

That's why I started building VidSyndicate.

👉 https://vidsyndicate.com

The Problem

Most social media tools focus on scheduling.

Scheduling is useful.

But scheduling doesn't solve the real bottleneck.

The real bottleneck is preparing content for every platform.

Creators today aren't just posting to one network anymore. They're publishing to LinkedIn, X, Facebook, Bluesky, Mastodon, YouTube, TikTok, Instagram, Pinterest, and whatever comes next. Every platform has different limits, audiences, and best practices.

Managing all of that manually quickly becomes a second full-time job.

Why I Built VidSyndicate

I wanted one place where I could:

Connect all of my social accounts
Upload a video or create a post once
Generate AI-assisted versions for each platform
Review everything before publishing
Schedule future content
Manage drafts
Publish everywhere from one dashboard

The emphasis is on assisted publishing, not spam.

A LinkedIn post shouldn't read like a Tweet.

A YouTube description shouldn't be copied directly into TikTok.

Automation should remove repetitive work—not authenticity.

AI Should Help, Not Replace You

One thing I wanted to avoid was "click once and blast identical content everywhere."

That usually creates poor engagement.

Instead, AI should help adapt content for each platform while keeping the creator in control.

For example:

Longer professional copy for LinkedIn
Short engaging captions for X
Optimized hashtags for Instagram
Better descriptions for YouTube
Platform-specific formatting

The human still approves everything.

AI simply removes the repetitive editing.

Building in Public

One of the most rewarding parts of this project has been building it in public.

I've been documenting everything:

UI redesigns
API integrations
SEO improvements
Infrastructure decisions
Meta App Review process
New AI features

Those conversations have often been more valuable than simply announcing new releases.

Developers appreciate seeing the journey—not just the destination.

Lessons Learned

Building software is rarely about writing code.

It's usually about removing friction.

The less time creators spend copying, pasting, resizing, and rewriting content...

...the more time they have to actually create.

That's the problem I'm trying to solve.

What's Next?

I'm continuing to add features every week.

Some upcoming improvements include:

Additional AI tools
Better publishing workflows
Enhanced analytics
More social network integrations
Improved onboarding
Video management features

The project is evolving quickly thanks to feedback from early users.

I'd Love Your Feedback

If you're a developer, indie hacker, marketer, or content creator, I'd love to know:

What's the most frustrating part of publishing content across multiple social platforms?

If you'd like to follow the project—or even try it for free—you can find it here:

https://vidsyndicate.com

Feedback is always welcome.

Thanks for reading!

Tags: webdev saas buildinpublic productivity ai

Recovering a Hacked WordPress Site and Rebuilding It with Laravel

Robert Saylor — Wed, 03 Jun 2026 10:16:15 +0000

Recently I was brought into a project involving a legacy WordPress website that had suffered a security incident. By the time I got access, parts of the site were no longer functioning correctly, content was missing, and the overall platform had become difficult to maintain.

At Custom PHP Design, we frequently help businesses modernize aging websites and web applications, but this project presented a unique challenge: recovering years of content while rebuilding the platform from the ground up.

The client wanted to preserve as much content as possible while moving to a more maintainable and secure platform.

Rather than attempting another WordPress recovery, we decided to rebuild the site entirely using Laravel.

Assessing the Damage

The first step was determining what could be recovered.

While portions of the site's database were available, the content was incomplete. Some pages existed only in archived versions of the website, while others had been modified or removed over time.

The challenge wasn't just rebuilding the application—it was reconstructing years of content.

Leveraging the Wayback Machine

One of the most valuable tools during the recovery process was the Wayback Machine.

Archived snapshots allowed us to:

Recover missing pages
Verify historical content
Rebuild navigation structures
Restore articles that were no longer present in backups
Cross-reference content against available database records

Many developers think of the Wayback Machine as a research tool, but in this case it became an essential part of the disaster recovery process.

Without those archived snapshots, a significant amount of content would have been permanently lost.

Why We Chose Laravel

Once we had a recovery strategy, the next decision was selecting a platform.

We chose Laravel because it provided:

A modern application architecture
Strong security defaults
Flexible routing
Better long-term maintainability
Full control over the data model
Simplified deployment workflows

Instead of fitting the project back into WordPress, Laravel allowed us to build exactly what the client needed.

Building the Migration Process

The migration involved more than simply importing content.

We had to:

Extract recovered content
Clean legacy HTML
Normalize URLs
Rebuild internal links
Restore media references
Generate SEO-friendly slugs
Validate imported records

To speed up the process, we built custom import scripts that transformed recovered content into Laravel models.

Automation handled the repetitive work while manual review ensured content quality.

Preserving Search Visibility

A major concern during any rebuild is SEO.

To minimize disruption, we focused on:

Preserving URL structures where possible
Implementing redirects
Generating XML sitemaps
Adding canonical URLs
Creating structured data
Maintaining internal linking

By treating SEO as part of the migration rather than an afterthought, we were able to launch the new platform without sacrificing discoverability.

Lessons Learned

A few things stood out during this project:

Backups Aren't Always Enough

Many organizations assume they can recover quickly from backups, but gaps often exist.

Archive Services Can Be Invaluable

The Wayback Machine provided access to content that was unavailable elsewhere.

Rebuilding Can Be More Efficient Than Repairing

In some situations, continuing to patch a heavily customized legacy system costs more than rebuilding on a modern framework.

Security and Maintainability Matter

Moving to Laravel gave the client a platform that was easier to secure, update, and extend.

Modern Frameworks Provide Long-Term Flexibility

By rebuilding the application in Laravel, the client now has a platform that can continue to evolve as business requirements change without being constrained by legacy plugins or themes.

Final Thoughts

This project started as a recovery effort but became an opportunity to modernize an aging platform.

By combining archived content from the Wayback Machine with custom migration tooling and a Laravel rebuild, we were able to preserve years of valuable content while delivering a faster, more maintainable application.

Sometimes the best recovery plan isn't restoring what existed before—it's building something better.

At Custom PHP Design, we specialize in Laravel development, legacy PHP modernization, AWS infrastructure, and custom web application development. Projects like this demonstrate how the right recovery strategy can turn a difficult situation into an opportunity to build a stronger, more secure platform for the future.

Modernizing a 10+ Year Old PHP Application into Laravel 12 (Historical Text Archive Case Study)

Robert Saylor — Sun, 29 Mar 2026 23:14:13 +0000

When you inherit a PHP application that has been running for over a decade, stability and technical debt often grow together.

That was the situation with the Historical Text Archive (HTA), a long-running content site containing hundreds of historical articles, primary sources, and educational material.

Over time, the original codebase became harder to maintain, harder to extend, and increasingly difficult to integrate with modern tooling.

Rather than continue patching the legacy system, we decided to modernize the platform using Laravel 12 while preserving the data structure and URLs that search engines already trust.

HTA is publicly available here:

https://historicaltextarchive.org

Goals of the Migration

We wanted to improve:

maintainability
security
search functionality
extensibility
performance
developer experience

while keeping:

existing URLs intact
article IDs stable
database structure understandable
SEO authority preserved

Challenges of Legacy PHP

The original application was built more than 10 years ago using procedural PHP and a MySQL database.

Common issues we encountered:

mixed business logic and presentation
limited separation of concerns
manual SQL queries everywhere
inconsistent naming conventions
limited testability
difficulty adding new features
older authentication approach

Despite these limitations, the schema itself was solid. The database structure had aged well, making it a good candidate for migration.

Migration Strategy

Instead of rewriting everything at once, we focused on incremental modernization.

High-level approach:

export existing database schema
generate Laravel migrations from schema
generate Eloquent models
replicate core functionality
preserve routes and URLs
add modern features
improve search capabilities

This approach reduced risk and allowed the application to remain functional during development.

Step 1: Converting SQL Schema into Laravel Migrations

We started with a schema.sql dump from the legacy application.

From there we generated Laravel migration files that recreated the structure in a fresh database.

Benefits:

version controlled schema
easier onboarding for future developers
consistent database structure across environments
rollback capability

Example migration:

Schema::create('articles', function (Blueprint $table) {
    $table->increments('artid');
    $table->integer('secid')->index();
    $table->string('title');
    $table->date('published')->nullable();
    $table->text('body');
});

Step 2: Generating Eloquent Models

Once migrations were in place, we created Eloquent models for each major table.

Example:

class Article extends Model
{
    protected $primaryKey = 'artid';

    protected $fillable = [
        'title',
        'secid',
        'published',
        'body'
    ];

    public function section()
    {
        return $this->belongsTo(Section::class, 'secid');
    }
}

Benefits:

structured ORM relationships
simplified queries
reusable logic
easier refactoring

Step 3: Preserving SEO-Friendly URLs

One of the most important requirements was preserving search engine rankings.

Many HTA articles have been indexed for years.

Breaking URLs would:

reduce search visibility
lose backlinks
create poor user experience

We maintained existing routes wherever possible:

Route::get('/articles/{artid}/{slug?}', [ArticleController::class, 'show']);

This allowed legacy URLs to continue working without redirects.

Step 4: Improving Search

Search is central to any archive.

The legacy system used simple SQL queries which worked but were limited.

Laravel makes it easier to:

expand search fields
add filters
build indexing logic
support future AI categorization

Example search query:

Article::query()
    ->where('title', 'like', "%{$search}%")
    ->orWhere('body', 'like', "%{$search}%")
    ->paginate(20);

Future improvements may include:

full text indexing
semantic search
tagging automation
historical topic clustering

Step 5: Modern Development Workflow

Laravel provides a modern toolkit:

migrations
artisan CLI
blade templates
validation rules
routing system
middleware
queue support
testing tools

Example artisan usage:

php artisan migrate
php artisan make:model Article
php artisan make:controller ArticleController

Development is now faster and more consistent.

Step 6: Preparing for Future Features

With Laravel in place, HTA can now expand into:

newsletter automation
"On this day in history" article discovery
improved article categorization
editorial workflow improvements
API endpoints
AI assisted tagging
advanced search capabilities

Because the foundation is now structured, new features are significantly easier to implement.

Key Takeaways

Migrating a legacy PHP application does not require abandoning everything.

In many cases:

the database design is still valuable
the content is still valuable
the domain authority is still valuable

Laravel allows modernization without losing what already works.

For HTA, the result is a platform that keeps its historical depth while gaining modern flexibility.

Live Site

https://historicaltextarchive.org

If you are working with a legacy PHP application, start with:

database migration
model structure
route preservation

Modernization can happen incrementally without disrupting users.

Sometimes the best upgrade is not replacing everything, but building a better foundation underneath what already exists.

VidShare Just Got Approved for Facebook, Instagram, and TikTok 🎉

Robert Saylor — Fri, 27 Mar 2026 16:10:28 +0000

This week was a big milestone for VidShare.

After weeks of development, testing, and API reviews, VidShare is now approved to publish video content to Facebook, Instagram, and TikTok, bringing us closer to the goal of making video distribution simple again.

VidShare started with a simple idea:

Upload once, shape the post, and publish across your video stack.

Creators shouldn’t have to upload the same video 5+ times just to stay consistent online.

And now, that workflow is finally becoming reality.

Why This Matters

Publishing video content across multiple platforms is still surprisingly manual.

Even experienced creators often:

Export the same video multiple times
Resize or tweak captions per platform
Upload separately to each social network
Try to keep everything scheduled consistently

This repetitive work slows creators down and makes consistency harder than it should be.

Social media scheduling tools have existed for years, helping marketers plan and publish content more efficiently across channels.

VidShare focuses specifically on video-first creators, simplifying the process of distributing video content across multiple platforms from one place.

Newly Approved Platforms

This week, VidShare received approval for:

Facebook video publishing
Instagram video publishing
TikTok draft publishing
LinkedIn video publishing (already available)
YouTube publishing
Pinterest video support
Additional platforms including Bluesky and Mastodon

With these approvals, creators can now manage most of their core video distribution workflow from a single dashboard.

Current Workflow Inside VidShare

The workflow is intentionally simple:

Upload your video once
Customize captions for each platform if needed
Choose publish time or schedule
VidShare distributes the content automatically

No more jumping between apps just to post the same content repeatedly.

TikTok Draft Support

One of the most requested features has been TikTok support.

TikTok’s API review process is known to be more restrictive than other platforms, particularly around content publishing permissions.

Instead of immediately publishing videos publicly, VidShare currently supports sending videos directly to the user's TikTok drafts inbox, giving creators full control before posting.

This provides a balance between automation and creative flexibility.

Why We Built VidShare

VidShare was created after experiencing the same frustration many creators have:

Uploading the same video repeatedly across platforms wastes time that could be spent creating better content.

Many existing tools focus heavily on analytics or enterprise workflows.

VidShare focuses on:

simplicity
speed
creator-first workflow
AI-assisted optimization
reducing repetitive tasks

The goal is not to replace creativity, but to remove friction.

What’s Next

Now that major platform approvals are in place, the roadmap becomes clearer.

Upcoming areas of exploration include:

improved scheduling workflows
bulk upload capabilities
expanded AI optimization tools
deeper integrations with additional platforms
improved creator discovery features

One step at a time.

Build in Public

VidShare is still early, but momentum is building quickly.

Recent milestones include:

Multi-platform publishing support
AI-assisted captions and descriptions
unified video calendar
OAuth integrations across major platforms
creator-focused workflow design

And now:

Facebook, Instagram, and TikTok approval.

Try VidShare

If you create video content and want to simplify distribution:

VidShare is designed to help you stay consistent without increasing workload.

Upload once. Publish everywhere.

Introducing Get Discovered: A New Way for Creators to Grow with VidShare

Robert Saylor — Thu, 19 Mar 2026 12:15:49 +0000

If you’ve ever uploaded content and felt like it just… disappeared into the void—you’re not alone.

One of the hardest parts of being a creator today isn’t making content.

It’s getting noticed.

That’s exactly why we built something new inside VidShare:

👉 Get Discovered*
https://vidshare.us/get-discovered

🎯 The Problem

Creators today are everywhere—YouTube, Instagram, TikTok, Pinterest… the list never ends.

Tools like VidShare already help solve one big issue:
upload once, distribute everywhere.

But distribution alone doesn’t solve visibility.

Because even if your content is everywhere…
it still has to compete with everything else.

💡 The Idea Behind Get Discovered

We wanted to flip the script.

Instead of chasing algorithms, what if creators had a dedicated space to be seen?

Get Discovered is exactly that:

A place where creators can feature themselves
A system where visibility is earned through engagement
A platform designed to help creators grow their audience organically

🔥 How It Works

Here’s the core concept:

1. Creators Sign Up (Free)

Anyone can create an account and join the discovery system.

2. Get Featured

Creators are scheduled into a featured window where they get visibility.

3. Community Voting

During that time:

Users can upvote creators
The most engaging creators rise to the top

4. Follow & Grow

Visitors can:

Click into creator profiles
Follow them on their platforms
Discover new content worth watching

🧠 Why This Matters

Most platforms are built around algorithms.

Get Discovered is built around:

People
Community
Fair exposure

It creates a level playing field where:

New creators can compete
Small creators can be seen
Great content actually has a chance to win

🔗 Built to Work With Your Existing Content

This isn’t another platform you have to “start over” on.

It works alongside everything you’re already doing:

Upload once with VidShare
Distribute everywhere
Then use Get Discovered to drive attention back to you

🚀 What’s Next

This is just the beginning.

We’re exploring:

Leaderboards
Creator tiers
Featured categories
Deeper analytics

👉 Try It Out

If you’re a content creator looking to grow your audience:

Check it out here:
https://vidshare.us/get-discovered

I Build a Tool to Stop Uploading the Same Video 5 Times

Robert Saylor — Wed, 18 Mar 2026 11:01:24 +0000

As a developer and a content creator, I ran into a problem that felt way more painful than it should be:

Uploading the same video… over and over… to different platforms.

My workflow looked like this:

Upload to YouTube
Upload again to Pinterest
Upload again to Twitch
Upload again to Mastodon
Upload again to Bluesky

Every. Single. Time.

It wasn’t just repetitive — it made it harder to stay consistent.

The Real Problem Isn’t Uploading — It’s Friction

At first, I thought the issue was just “too many platforms.”

But after doing this repeatedly, I realized something deeper:

The real problem is friction between platforms.

Each platform:

has its own upload flow
its own UI
its own quirks
its own timing

Even small differences add up.

And when posting becomes annoying, consistency drops.

What I Built (For Myself First)

So I built a tool called VidShare.

The idea is simple:

Upload once → distribute everywhere.

Instead of repeating the same process 5 times, I wanted a single workflow:

Upload video once
Select platforms
Let the system handle the rest

What Works Today

Right now, VidShare supports:

YouTube
Pinterest
Twitch
Mastodon
Bluesky

Some platforms were easy.

Others… not so much.

The Hardest Part Wasn’t the Code

Surprisingly, building the system wasn’t the hardest part.

Getting platform approvals was.

If you’ve ever worked with APIs like Meta or TikTok, you already know:

strict permission reviews
unclear requirements
multiple submission cycles

At one point, I had to build an entire UI just to prove I was using a permission correctly.

What I Learned Building This

1. Repetition is a product opportunity

If something feels annoying every time you do it, there’s probably a product hiding there.

2. APIs are the real bottleneck

You can build fast — but approvals slow everything down.

3. Consistency beats perfection

Making it easier to post consistently is more valuable than optimizing each post individually.

Where This Is Going

I’m currently working through approvals for:

Facebook
Instagram
TikTok

Once those are in, the workflow becomes much more powerful.

Final Thought

Most creators don’t struggle with making content.

They struggle with distributing it efficiently.

That’s the problem I’m trying to solve.

If you're dealing with the same issue, I’d love to hear how you're handling multi-platform posting.

Are you doing it manually, or using tools to streamline it?

If you're dealing with the same problem, you can check it out here:

👉 https://vidshare.us

Would love to hear how you're handling multi-platform posting.

I got tired of uploading videos to multiple platforms, so I built this

Robert Saylor — Tue, 17 Mar 2026 12:33:53 +0000

If you create video content, you probably know this workflow:

Record or edit a video

Upload to YouTube

Then upload the same video to TikTok

Then Instagram

Then maybe Pinterest or others

Each platform has its own process, formatting, scheduling, and quirks.

What should be simple turns into a repetitive, time-consuming task.

I ran into this myself after growing a small audience on TikTok. When I started posting to YouTube and other platforms, I realized I was spending more time uploading and managing posts than actually creating content.

And it only gets worse as you scale.

The problem isn’t creating content anymore — it’s distributing it.

So I built a tool to solve that.

VidShare is a platform that lets you upload your video once and distribute it across multiple platforms without repeating the same steps over and over.

Instead of:
Upload → configure → post → repeat

It becomes:
Upload once → select platforms → schedule → done

The goal isn’t to replace any platform, but to remove the friction between them.

Right now, creators are stitching together workflows manually, even though the content is often the same across platforms.

It feels like something that should have been solved already.

I’m still early in building this, and currently looking for creators who want to test it and give feedback.

If you’re dealing with the same problem, I’d genuinely like to hear how you’re handling it today.

Also curious — do you think this is something platforms will eventually solve themselves, or will third-party tools always fill the gap?

If you want to check it out or try it:
https://vidshare.us