We Don't Have GPUs — Can We Still Run a PoC? Why AI Is an Optional Layer
The answer we give institutions that want a PoC but have no GPUs. Only the agent needs GPU; everything else on the platform runs on CPU servers. How the 30-day PoC actually proceeds, how much of document generation is really automatic, and why "we should validate fit before adopting" is exactly right.
There's a moment late in meetings, once adoption talk gets concrete, that goes the same way every time. "We should probably validate with a PoC first — but we don't have GPUs. Is that possible?"
It is. And the point of this post is that this answer is a design decision, not a coincidence.
Can we run a PoC without GPUs?
Yes. Only the AI agent requires GPU; the entire rest of the platform (issues, change requests, repositories, pipelines, documents, dashboards, permissions) runs normally on CPU servers. The minimum footprint is one VM with 8 vCPU, 16 GB RAM, and 200 GB disk, a spec any institution's virtualization farm can produce in a day.
We designed it this way after watching how public-sector adoption actually sequences. Internal approval for AI features is slow: data-handling review, security review, and GPU procurement itself is a separate budget cycle. If AI and the platform are one inseparable block, that slow approval takes the whole adoption hostage. Separated, version control, change tracking, and evidence automation can start validation now, and the agent gets added when the GPUs and the sign-offs are ready. The sizing conversation for when that day comes is in a separate post.
How does the PoC actually proceed?
The standard track is 30 days, in four steps. About a week of environment alignment (firewalls, account systems, which repositories come in scope), roughly four hours for installation, then 30 days of operation, and finally the adoption decision. Before installation there's a preflight check that sweeps everything from OS version to storage, ports, and time sync, which keeps installation day from burning hours on finding out why nothing works. In an air-gapped network, the same procedure runs from the offline install bundle.
What should you look at during the 30 days? Our recommended validation is unglamorous: have one real team push one real task through it. Run a full cycle from issue registration through change-request approval to deployment, and check that the evidence it leaves behind is in a form your audits can actually use. A feature demo takes a day. The 30 days exist to see whether this flow holds up under that organization's approval habits and security rules.
On this point, one remark from a meeting has stayed with me: "The right thing is to validate through a PoC whether it fits our organization, and then use it." A vendor could hear that as deflating. I think it's exactly correct. There is a real gap between how they work today and how our platform works, and whether that gap closes in that organization is proven by operating records, not slide decks — the same argument as stability is the reference. The adoption paths we've distilled from 17 PoCs, by environment type, are in five kinds of on-prem environments.
Are documents generated automatically?
Draft generation is automatic; finalization is human. That boundary is the whole point. From everyday documents (change-request descriptions, meeting minutes, release notes) to public-sector project deliverables (requirements traceability matrices, task-comparison tables, change-management ledgers, test reports, deployment reports), drafts are produced from the real records accumulated in the platform (issues, commits, approvals, deployment logs) and exported to Excel or PDF. Because the underlying data lives in the system, the human job changes from composing on a blank page to reviewing and correcting.
I want to be clear this is not "it's automatic, so no humans needed." Final responsibility for deliverables stays with people; our design principle is literally "AI does the work, humans make the decision." And in the GPU-less PoC configuration, the AI drafting part starts out absent. What remains is still substantial: the mere fact that a deliverable's source data accumulates in one place eliminates the hunting-and-gathering that used to consume most of document-writing time.
If you're the one evaluating adoption, here's the sequence I'd recommend. Forget the GPUs, run 30 days on a single CPU server, and confirm the value of version control and evidence first. If the organization decides it fits, starting GPU procurement and AI approval then is not too late. The reverse order, leading with the GPU budget, stalls the entire adoption the moment the AI sign-off hits a wall. Which is exactly why we didn't build it that way.
Related posts
How Much of "Git Is Risky, SVN Is Safe" Holds Up? An Operations Comparison Table
Security comparisons of Git and SVN mix two separate questions: where the repository runs and what gets replicated to developers. Using official documentation, this post compares five items in a table (internal hosting, local copy scope, per-path read separation, egress, access revocation) and ends with a checklist for a source control security review.
John Baek
Is Git Safe for Government Agencies on an Internal Network? What the Public Record Says
Asked whether Git can run in a closed network at all, I checked the official docs, government announcements, and procurement records. The answer is yes, internal-network Git can be operated safely. Here are the evidence, the two design decisions that make it so, and a question list for security reviews.
John Baek
But We Lock Files Before Editing — Moving from Lock-Based SCM to Concurrent Development
There's a question we get in almost every public-sector meeting. We lock a file before we touch it — so how does your solution work? On the difference between lock-based and branch-merge models, how control survives without locks, and a migration path that doesn't throw away history.
John Baek