Building a VMS With ChatGPT vs. Buying an AI-Powered Enterprise VMS | Resources

We Tried to Build a VMS With AI. Here Is What We Learned.

There is a new question making its way into technology and procurement conversations:

If AI can build software, why should enterprises buy software anymore?

It is a fair question.

Modern AI coding tools can generate Python, JavaScript, SQL, APIs, database schemas, and entire application components in seconds. Large language models can explain code, write tests, troubleshoot errors, and even help architects design systems.

So, let us take the question seriously.

Imagine your organization needs a Vendor Management System to manage its contingent workforce.

Why not simply give ChatGPT the requirements and ask it to build one?

No license, no long implementation project or waiting for a software roadmap. Just your engineers, an AI coding assistant and a cloud environment.

Sounds compelling.

So, we tried it.

And what we discovered was more interesting than simply proving that AI can write code.

 AI absolutely can help you build a VMS.

The real question is how much of a VMS you have after the code is written. Because there is a huge difference between:

 Building software that performs a VMS function.

and

 Building an enterprise VMS that an organization can trust with its workforce, suppliers, spend, compliance, and business processes.

That difference is where the build versus buy conversation gets very interesting.

Let’s get started.

Experiment 1: Let's Build a Requisition

We will start with one of the most basic VMS capabilities. A hiring manager needs to create a contingent workforce requisition.

This was our prompt for AI coding assistant:

Build a Python API that allows a hiring manager to create a requisition with job title, location, required skills, bill rate and currency.

The generated looked something like this:

from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI()

class Requisition(BaseModel):
title: str
location: str
skills: list[str]
bill_rate: float
currency: str

@app.post("/requisitions")
def create_requisition(req: Requisition):

return {
"status": "created",
"requisition": req.model_dump()
}

That’s it. We have an API. We can run it, send a request, and receive a response.

We have built a requisition endpoint. And now the real requirements begin.

Now, you might have questions like:

• Who can create requisitions?
• How to integrate multiple business units?
• What if the requested rate exceeds the approved rate?
• What happens if the approver is on vacation?
• Who can edit the requisition after approval?
• What happens when the bill rate changes?
• Can an auditor see the complete history?

Suddenly, our 20 lines of Python have become a business process.

And that gives us our first lesson:

The difficult part of enterprise software is rarely the first feature. It is everything that feature needs to work with.

Experiment 2: Let's Add Approval Logic

Next up, we will add approval.

Let’s consider a business situation:

Any requisition above $100 per hour requires Procurement approval.

def determine_approval(requisition):

if requisition["bill_rate"] > 100:
return "PROCUREMENT"

return "HIRING_MANAGER"


Let's test it.

requisition = {
"title": "Senior Data Engineer",
"location": "New York",
"bill_rate": 145,
"currency": "USD"
}

approval = determine_approval(requisition)

print(approval)

Output:

PROCUREMENT

Now, the business changes the requirement. The threshold is different for every country.

Then different business units have different thresholds, and certain job categories have different thresholds. Plus, contracts longer than 12 months require additional approval.

Then certain cost centers have different approval limits. Then there are exceptions.

Our little function starts turning into something like:

Country
Business Unit
Cost Center
Job Category
Worker Type
Bill Rate
Contract Duration
Supplier
Supplier Agreement
Existing Budget
Approval Authority
Exception Rules

And now we need:

Rule versioning, effective dates, approval matrices, delegation, escalation, notifications, exception handling, audit history, testing, configuration.

The original Python code was easy.

The business rules were the product.

Experiment 3: Let's Add AI Candidate Matching

Now we get to the exciting part. We want our VMS to help recruiters find the right candidates.

Imagine this requisition:

job = {
"title": "Senior Data Engineer",
"location": "New York",
"skills": [
"Python",
"AWS",
"Kubernetes"
],
"experience": "8+ years"
}

And this candidate:

candidate = {
"id": "CAND-1024",
"skills": [
"Python",
"AWS",
"Docker",
"Kubernetes"
],
"experience": "9 years"
}

Instead of relying only on keyword matching, we can ask an LLM to evaluate the candidate against the requirement.

A simplified implementation could look like:

client = OpenAI()

def match_candidate(job, candidate):

prompt = f"""
Evaluate this candidate against the job requirement. 

JOB:
Title: {job["title"]}
Skills: {", ".join(job["skills"])}
Experience: {job["experience"]}

CANDIDATE:
Skills: {", ".join(candidate["skills"])}
Experience: {candidate["experience"]}

Return:
1. Match score from 0 to 100
2. Matching skills
3. Missing skills
4. Relevant experience
5. Short recommendation
"""

response = client.responses.create(
model="YOUR_MODEL",
input=prompt
)

return response.output_text

Then:

result = match_candidate(job, candidate)
print(result)

We might get something like:

 We ran another test, with a candidate: 

 And the match score was different: 

Now, it feels like we are going somewhere.

A few lines of Python have turned a traditional search experience into an AI-assisted matching capability.

This is where the argument for building starts to sound very convincing.

If AI can help us build intelligent workforce capabilities quickly, why buy an AI-powered VMS?

The Enterprise Layer Appears

Before we send candidate information to an AI model, we need to think about permissions.

Is the user authorized to view the candidate? What candidate information can the model access? Should sensitive information be excluded? Should certain attributes be masked? How do we prevent unauthorized data from entering the AI workflow?

A simplified control layer might look like:

def evaluate_candidate(job, candidate, user):

if not user.has_permission("VIEW_CANDIDATE_DATA"):
raise PermissionError(
"User is not authorized"
)

safe_candidate = {
"skills": candidate["skills"],
"experience": candidate["experience"]
}

result = match_candidate(
job,
safe_candidate
)

audit_log(
user=user.id,
action="AI_CANDIDATE_MATCH",
candidate_id=candidate["id"]
)

return result 

The architecture is now:

Notice what happened. The AI model is still relatively simple. The enterprise controls surrounding it are getting complicated.

This pattern repeats throughout the entire VMS.

Experiment 4: Let's Give AI the Ability to Act

Now let's move beyond AI-generated recommendations.

What if AI could actually perform work?

Imagine telling an AI agent:

Find the best suppliers for this requisition, analyze their historical performance, prepare the supplier request and wait for Procurement approval before sending it.

We can expose tools to the agent.

def find_suppliers(skill, location):

return supplier_database.search(
skill=skill,
location=location
)


def check_supplier_performance(supplier_id):

return supplier_database.performance(
supplier_id
)


def create_supplier_request(
supplier_id,
requisition_id
):

return supplier_portal.send_request(
supplier_id=supplier_id,
requisition_id=requisition_id
)

Now our AI agent can potentially orchestrate these capabilities.

Conceptually:

This is where AI becomes genuinely transformative. But it also changes the risk profile.

A chatbot that provides information is one thing. An AI agent that can call enterprise APIs is something else entirely.

We have to consider things like:

• What can the agent access?
• Which tools can it call?
• What actions require human approval?
• Can it modify a requisition?
• Can it contact a supplier?
• Can it access commercial information?
• Can it approve an invoice?
• Can it execute the same action twice?
• How do we stop an incorrect action?
• How do we audit it?

The more autonomy we give AI, the more important the surrounding enterprise architecture becomes.

And We Still Haven't Built the VMS

At this point, we have – A requisition API, approval logic, AI matching, permission controls, and AI agent tools.

Yet, we have barely scratched the surface.

That’s because a real VMS also needs capabilities around:

• Supplier management
• Worker onboarding
• Compliance
• Rate management
• Timesheets
• SOW and services procurement
• Invoicing
• Reporting & Analytics
• Auditability
• Integrations
• Security
• Global configuration

Now imagine building each of those capabilities, connecting them, testing them, supporting them, securing them, and adapting them every time the business changes.

The project has stopped being:

“Let's build a VMS with ChatGPT.”

It has become:

“Let's become a VMS software company.”

And that is a very different proposition.

The Integration Reality

A VMS does not operate in isolation. It sits inside the enterprise technology ecosystem.

A simplified environment could look like:

Then add identity providers, background screening, job boards, timekeeping, payroll, finance, procurement, data warehouses, business intelligence, supplier systems, email, messaging, and document management.

Every integration brings its own engineering requirements around authentication, authorization, data mapping, transformation, validation, retries, idempotency, error handling, logging, monitoring, versioning, and testing.

Imagine the HRIS sends an organizational update and the VMS receives it.

What happens if the request arrives twice, a field is missing, the HRIS changes its schema, the VMS processes the update, but the response fails, the endpoint becomes unavailable, or the integration needs to be adapted for another country?

The API might take a day to write, but making the integration reliable for years is the real work.

Then There Is Compliance

Let's take another seemingly simple requirement:

A worker cannot start an assignment until required compliance checks are complete.

A basic Python function might be:

def check_compliance(worker):

required_documents = [
"ID",
"Work Authorization"
]

return all(
document in worker.documents
for document in required_documents
) 

It works.

But enterprise compliance rarely consists of two documents.

Requirements can vary by country, worker classification, engagement type, job category, assignment, contract, expiration date, and more.

Now imagine, rule change, exceptions, and compliance failures.
Now our simple function is no longer a function.

Again, AI can help engineers build it.

But AI does not eliminate underlying responsibility.

What Does Building Actually Mean?

This is where the build versus buy equation becomes very different from what it initially looked like.

At the beginning, the calculation seems simple:

Build with AI + Developer + Cloud = VMS

In reality:

AI Assisted Development + Architecture + Engineering + Infrastructure + Security + Data + Integrations + Testing + Compliance + Monitoring + Support + Maintenance + AI Governance = Enterprise VMS

And there is one more aspect that rarely appears on the spreadsheet.

OPPORTUNITY COST!

Your engineering team has limited capacity. If the next 12 to 24 months go into building supplier management, requisitions, worker management, compliance, timesheets, invoicing, reporting, integrations, AI matching, and AI agents, what are they not building? Your proprietary workforce intelligence, internal automation, predictive analytics, and next generation business capabilities.

AI can make developers dramatically more productive. But that makes the question even more important: Where should you deploy that productivity? Building another VMS, or building what makes your business uniquely competitive?

This Is Where an AI-First VMS Changes the Equation

Now let's consider the alternative.

Instead of building the entire foundation, buy an enterprise VMS that is already designed to manage the external workforce and has AI embedded into its architecture.

You are no longer buying:

Old software and adding AI later.

You are buying:

An enterprise workforce platform designed to use AI as part of the experience, workflow and architecture.

That distinction matters.

The VMS already provides the foundational capabilities.

AI then operates across that foundation.

Now the conversation changes.

You are not asking: “Can we build AI?”

You are asking: “How much more can we accomplish because the enterprise foundation already exists?”

An AI-First VMS Is Not Just a VMS With a Chatbot

This distinction is important.

Adding a chatbot to an existing VMS does not automatically make it AI first.

An AI first VMS should be designed around AI assisted experiences, automation, intelligence and increasingly autonomous workflows.

Think about the difference.

A traditional VMS might require a hiring manager to:

1. Create a requisition.
2. Search suppliers.
3. Review candidates.
4. Compare rates.
5. Check compliance.
6. Monitor submissions.
7. Review supplier performance.
8. Manage approvals.

An AI first VMS can progressively assist with those decisions.

• AI can help generate requisition.
• AI can recommend suppliers.
• AI can match candidates.
• AI can automate L1 and L2 interviews
• AI can benchmark rates.
• AI can identify compliance risks.
• AI agents can orchestrate workflows.

The human remains in control where judgment and approval are required.

But the system does more work. That is the real value of AI.

Not replacing the VMS. Making the VMS dramatically more capable.

There Is Another Advantage: Continuous Innovation 

When you build your own platform, your VMS only evolves as fast as your engineering team can keep up.

New AI models, agent capabilities, security practices, enterprise expectations, and workforce requirements all mean more development and maintenance.

With an AI first VMS, the platform provider carries much of that ongoing investment.

New AI capabilities, automation, integrations, and security improvements can evolve continuously without forcing your team to rebuild the foundation.

You are not simply buying software. You are buying into a technology platform that keeps evolving.

The Economics of Engineering Capacity

There is a simple question every CIO, CTO and procurement leader should ask:

What is the highest value of our engineering capacity?

If your business makes money by selling VMS software, building one might make perfect sense.

If your business is a bank, pharmaceutical company, retailer, manufacturer, technology company, or healthcare organization, the answer may be very different.

Your competitive advantage probably does not come from having the world's best internally built supplier portal.

It comes from your products, customers, intellectual property, operations, workforce strategy, and your data.

Ultimately, it’s about your ability to move faster than competitors.

That is why buying an AI first VMS can actually be an investment in innovation, rather than an alternative to innovation.

You are buying the foundation so your people can focus on what matters above it.

So, What Did Our Experiment Prove?

We started with a simple request:

Build a VMS. Within a few lines of Python, we created a requisition API.

Then we added approval logic, AI matching, permissions, auditability, AI agents, integration, and compliance.

And every time, AI made development easier. In fact, AI has made software development more accessible.

But it has also revealed something important.

The value of an enterprise platform is not simply in the code. It is in the ecosystem around the code.

Conclusion: The Question We Should Be Asking Now

The question is no longer:

“Can ChatGPT build our VMS?”

It probably can.

The better question is:

“What could our organization build if we didn't have to spend our engineering capacity building the VMS?”

That is where the real AI opportunity lies.

To build predictive workforce planning instead of another approval engine.

To build intelligent rate strategies instead of another timesheet workflow.

To build AI agents that transform your business instead of rebuilding infrastructure that an enterprise VMS already provides.

That is the strategic advantage of buying an AI-first VMS.

You are not choosing software instead of AI. You are choosing AI on top of enterprise software that is already built for the job.

And that is a much more powerful proposition.

AI is changing not only how VMS platforms are built, but also how enterprises manage their external workforce. Here are a few more perspectives worth exploring: 

What It Takes to Get Your CTO on Board With a VMS
11 Signs Your Services Procurement Has Outgrown Spreadsheets
How AI Helps Healthcare Organizations Solve Staffing Gaps