Part 1 of this series established why every AI-dependent business needs a continuity plan and introduced Ollama as the most practical local AI runtime for that role. This part addresses the implementation. Hardware first, because every decision after it depends on hardware reality. Installation second, with the configuration choices that matter for production failover use.
By the end of this guide, Ollama will be running on the target hardware, models will be downloaded, and the foundation for a working continuity plan will be in place. The remaining two parts of the series cover model selection with monitoring, then security and auto-failover integration.
What hardware does Ollama actually need?
Ollama is software. The constraint on whether it works for a business is the hardware it runs on. Three hardware paths qualify for production use, one path does not, and the difference between them is roughly an order of magnitude in response speed.
NVIDIA GPUs (Linux and Windows)
NVIDIA is the most common business path. Ollama requires Compute Capability 5.0 or higher, which includes the GTX 960 and every NVIDIA card released since 20151. The driver version must be 535 or higher on Linux, or 531 or higher on Windows. Modern data center cards (A100, H100, L40S) work and provide significant headroom for larger models.
Verification is a single command. Run nvidia-smi in a terminal. The output shows the driver version and lists available GPUs. If the command is not found or shows errors, the driver is missing or outdated and must be installed before Ollama will use GPU acceleration.
Apple Silicon (M1 through M4)
Apple Silicon is the simplest path. M1, M2, M3, and M4 chips all support Ollama through Metal GPU acceleration with zero configuration2. Install Ollama and it uses the GPU automatically. The unified memory architecture is particularly effective for large models because GPU and CPU share the same memory pool, which means a 32 GB Mac can load models that would require dedicated 32 GB GPU cards on PC hardware.
Intel Macs are not viable. Even on a high-end Intel i9 MacBook Pro, generation speed is in the 4 to 6 tokens-per-second range, similar to CPU-only operation on PC hardware.
AMD GPUs (Linux only, as of mid-2026)
AMD support is real but limited. ROCm 7 on Linux works for most modern AMD GPUs1. ROCm on Windows is still classified as experimental and is not officially supported by Ollama. Organizations standardized on AMD GPUs on Windows should plan around this reality, either by switching the AI workload to Linux, using WSL2 with the understanding that performance and stability vary, or running Ollama on CPU as a stopgap.
Hardware sizing by model
Different models require different amounts of memory. The table below shows the recommended hardware tier for each common model at standard quantization (Q4_K_M, which is the default in Ollama and balances quality with memory efficiency).
| Available Memory | Recommended Model | Typical Speed | Best For |
|---|---|---|---|
| 8 GB RAM (CPU only) | phi3:mini or gemma2:2b |
3 to 8 tokens/sec | Simple Q&A only, not viable for production |
| 16 GB RAM (CPU only) | llama3.1:8b |
5 to 10 tokens/sec | Still too slow for most workflows |
| 8 to 12 GB VRAM (NVIDIA) | llama3.1:8b, qwen2.5-coder:7b |
50 to 70 tokens/sec | Email, documents, code generation |
| 16 GB unified memory (Apple) | llama3.1:8b |
40 to 60 tokens/sec | General business workflows |
| 24 GB VRAM (RTX 3090, 4090, A5000) | qwen2.5-coder:14b, llama3.1:70b (tight) |
30 to 100 tokens/sec | Complex reasoning, near-frontier quality |
| 48 GB+ VRAM or 64 GB+ unified | llama3.1:70b with headroom |
20 to 50 tokens/sec | Highest-quality local inference |
The pattern in the table is consistent: GPU acceleration delivers roughly 10x to 20x faster generation than CPU-only operation. For business failover, only the GPU rows are viable.
Should the organization self-host or stick with cloud AI?
Not every organization should build local AI infrastructure. The hardware investment and engineering time matter. A practical decision framework looks at three factors.
Existing hardware. If the team already runs machines with compatible GPUs (developer workstations with NVIDIA cards, Apple Silicon laptops, or Linux servers with discrete GPUs), the marginal cost of adding Ollama is engineering time only. If no suitable hardware exists, the conversation shifts to whether a continuity plan justifies a hardware purchase.
Operational criticality. If the business pauses meaningfully when cloud AI fails (development teams blocked, customer support degraded, content production stopped), local AI failover is justified. If AI use is exploratory or non-critical, the case for local infrastructure is weaker.
Data sensitivity. Organizations handling regulated data (healthcare, legal, financial) often need local AI for reasons beyond continuity. Local execution keeps prompts and responses inside the corporate network, which simplifies GDPR, HIPAA, and SOC 2 compliance.
How is Ollama installed on macOS?
macOS is the fastest path to a working installation. The graphical installer handles everything, including the system service setup that makes Ollama available after restart.
Download the macOS installer
Visit ollama.com and download the macOS package. The download is approximately 200 MB.
Run the installer and grant permissions
Open the downloaded file and drag Ollama to the Applications folder. Launch Ollama. macOS prompts for permission to install the command-line tools. Approve the prompt. Ollama now runs as a menu bar application and starts automatically at login.
Verify the installation
Open Terminal and run the verification commands:
If both commands succeed, Ollama is installed and the API server is listening. The next step is downloading a model.
How is Ollama installed on Linux?
Linux installation requires a few more steps than macOS, but the result is a more robust production deployment. The official installer creates a systemd service with automatic restart on failure, which is the right baseline for business use.
Run the installer
Execute the one-line install script. The script handles dependency detection, GPU driver verification, and systemd service creation:
The installer creates an ollama system user and installs the binary to /usr/local/bin/ollama. Model storage defaults to /usr/share/ollama/.ollama/models.
Verify the service is running
Check the systemd service status:
Configure environment variables for production use
The default installation binds Ollama to localhost only and stores models in the system partition. For production deployments, these defaults often need adjustment. Edit the systemd service:
Add the configuration under the [Service] section. The most common production variables:
Save the file and reload the service:
Confirm GPU detection (NVIDIA only)
If the machine has an NVIDIA GPU, verify Ollama is using it:
The output should mention CUDA initialization and list the detected GPU. If it shows CPU mode despite an installed GPU, the driver version is likely below the minimum (535 on Linux). Update the NVIDIA driver and restart.
How is Ollama installed on Windows?
Windows installation uses an MSI installer or the winget package manager. Both produce the same result: Ollama running as a system tray application with the API server listening on localhost:11434.
Install Ollama
Two paths work. Either download the MSI from ollama.com and run it, or install via PowerShell with winget:
The installer adds Ollama to the system PATH and starts the background service.
Verify the installation
Open a new PowerShell or Command Prompt window (a new session is required for PATH updates to take effect):
Both should succeed. The Ollama system tray icon should also be visible.
Configure environment variables
Ollama on Windows reads environment variables from the user and system environment. Quit Ollama from the system tray, then open System Properties through the Settings app or Control Panel. Add environment variables:
OLLAMA_HOST=0.0.0.0:11434(only with firewall in place)OLLAMA_MODELS=D:\OllamaModels(redirect to larger drive)OLLAMA_KEEP_ALIVE=30m
Restart Ollama from the Start menu. The new environment variables take effect on the next launch.
How are models downloaded and tested?
With Ollama installed and running, the next step is pulling the model library that the failover system will use. Pull all models during normal operations, while the network is available. Once downloaded, models live locally and require no internet access to run.
Test each model with a real prompt to confirm output quality and response speed before relying on it for failover:
A well-functioning installation responds within seconds and produces coherent output. If response time exceeds 30 seconds for a short prompt on a GPU-equipped machine, the model is probably running on CPU. Verify GPU acceleration is active.
Does PCG handle Ollama deployment for clients?
Phoenix Consultants Group has been deploying production software systems since 1995, and the operational discipline that applies to legacy migrations and compliance platforms applies equally to local AI infrastructure. A custom Ollama deployment engagement starts with a hardware audit (what compatible machines already exist on the network), continues through installation and configuration tailored to the client's operating systems, and ends with team training on the operational procedures that keep the failover ready.
The same engineering team that builds and maintains the FireFlight Data System manages Ollama deployments. Both involve infrastructure that has to run continuously without manual babysitting, which is what PCG has built for three decades.
Need help deploying Ollama in production?
PCG handles hardware assessment, multi-platform installation, monitoring integration, and team training as a single engagement.
Frequently Asked Questions
What GPU do I need to run Ollama for business use?
Can Ollama run on an AMD GPU on Windows?
How much disk space does an Ollama installation need?
Should I install Ollama as a system service or run it manually?
Where does Ollama store the downloaded models?
Do I need to keep Ollama running all the time?
Sources
1 Ollama official GPU support documentation, NVIDIA and AMD requirements: github.com/ollama/ollama/blob/main/docs/gpu.md
2 Ollama documentation on Apple Silicon and Metal GPU acceleration: docs.ollama.com
3 Ollama Linux installation and systemd configuration: docs.ollama.com/linux
4 Ollama environment variable reference: github.com/ollama/ollama/blob/main/docs/faq.md
Continue Reading
Get the full installation guide
This is Part 2 of a 4-part series on building an AI continuity plan with Ollama. Enter your email to unlock the rest of this article and receive Parts 3 and 4 covering monitoring, model selection, firewall configuration, and auto-failover integration.
We verify your email first. One click confirms your subscription.
Custom .NET beats off-the-shelf SaaS in four specific situations: when business logic is too specific for any vendor template, when integration cost exceeds the license cost, when SaaS pricing scales worse than custom ownership at the business's volume, and when data sovereignty or compliance requirements rule out shared cloud platforms.
Most CEOs encounter the SaaS-versus-custom question the same way: a department head is frustrated with the current SaaS product, a vendor proposal arrives for a custom build, and there is no framework for assessing whether the proposal addresses a real problem or whether a different SaaS subscription would solve the situation more cheaply. This choice is not theoretical. The wrong answer in either direction costs measurable money, and the right answer depends entirely on the specific business situation rather than on general claims from either category of vendor.
Phoenix Consultants Group builds custom .NET applications and has done so since 1995, across more than 500 production engagements. PCG also routinely recommends SaaS when SaaS is the right answer. The honest version of this article is the one a CEO needs: a framework for distinguishing the situations where each approach wins, written by a company that has no interest in selling custom development when SaaS would solve the problem.1
When does SaaS actually win the decision?
SaaS is almost always the right starting point. If a packaged product matches the work the business does, the recommendation is to purchase it.2 The conversation about custom development begins when commercial software no longer accommodates the operation, not before. CEOs evaluating the question should start by identifying whether their situation matches the standard SaaS pattern. Most situations do, which is why most businesses run on commercial software rather than custom applications.
Standard workflow is the first signal that SaaS is the right choice. When the business runs a workflow that hundreds or thousands of other businesses run in essentially the same way, a SaaS vendor has already built the application. Accounting, CRM, project management, helpdesk, payroll for businesses without compliance specifics, expense reporting, and similar functions have mature SaaS markets with multiple competing products. The CEO's job is to select the best product for the specific business, not to commission a custom build.
Small IT footprint is the second signal. SaaS shifts operational responsibility to the vendor: backup, patching, security updates, and hardware capacity are the vendor's problem. For businesses with small IT teams that cannot productively manage on-premise infrastructure, SaaS removes a category of work the business does not want to own. The recurring license fee is the cost of avoiding that operational burden. That trade is rational for many businesses and remains so for as long as the SaaS product fits the work.
Low user volume is the third signal where SaaS pricing remains favorable. Most SaaS products are priced per user per month. At small user counts, the monthly fee is materially lower than the upfront development cost of a custom application that would do the same work. The math changes at higher user volumes, which is where the custom case begins to surface, but it remains favorable to SaaS at the small end of the volume spectrum.
Fast implementation requirement is the fourth signal. SaaS products typically deploy in days to weeks. Custom development runs in weeks to months depending on scope. When the business needs an operational capability now, and the SaaS market has a product that approximates the requirement, the speed advantage of SaaS frequently outweighs the long-term cost difference. The custom rebuild can happen later if needed.
What are the four situations where custom .NET beats SaaS?
The custom case is not the inverse of the SaaS case. It does not surface when "SaaS is bad." It surfaces in four specific situations where the structural assumptions that make SaaS economical break down for a particular business. CEOs who recognize one or more of these situations in their operation have a real reason to consider custom development. Businesses that do not match any of them should remain with SaaS.2
Business logic too specific for any vendor template
The business operates on rules, calculations, or workflows specific enough that no SaaS template encodes them correctly. Staff end up working primarily in spreadsheets that sit alongside the SaaS product, doing the calculations the platform cannot.
Integration cost exceeds license cost
The business runs three to five SaaS subscriptions that were each purchased to fill a gap in another. The integration burden between them, measured in staff time and middleware fees, exceeds the recurring license cost of the SaaS portfolio itself.
SaaS pricing scales worse than custom at volume
Per-user, per-record, or per-transaction fees compound until the recurring cost of SaaS surpasses the amortized cost of a custom application that does the same work. The crossover point depends on the specific volume and vendor pricing.
Data sovereignty or compliance rules out shared cloud
Regulatory frameworks or contractual obligations require that the business data reside on infrastructure the business controls. SaaS architectures, which depend on shared cloud platforms operated by the vendor, are excluded by the underlying compliance requirement.
Each of the four situations is independently sufficient to make custom development the right answer. They do not need to compound. A business that hits any one of them has a legitimate custom case. Operations that hit two or more have a case so strong that the CEO who continues running SaaS workarounds is actively losing money the business could redirect.1
How does SaaS pricing scale compared to custom .NET ownership?
The pricing structures of the two approaches are fundamentally different, and CEOs who do not understand the difference make the comparison incorrectly. SaaS is a recurring operating expense that scales with usage. Custom .NET is a capital investment that amortizes across the application's productive life. The two are not directly comparable on a monthly basis, but they are comparable across a multi-year horizon if the analysis is done correctly.
SaaS pricing typically follows one of three models. Per-user fees charge a fixed amount per active user per month, which scales linearly with headcount. Volume-based pricing charges based on the records stored or processed, which scales with the business's operational activity. Transaction-based pricing charges based on specific actions taken in the platform, which scales with the throughput of whatever process the SaaS supports. Most SaaS products use one of these models or a combination, and the model determines how the recurring cost grows over time.
Custom .NET ownership has a different cost profile. The upfront development cost is significant. After deployment, the recurring cost is hosting infrastructure, periodic maintenance, and any feature additions the business commissions. For a business operating at low user volumes, the SaaS recurring cost is materially lower than the amortized cost of custom development across the same period. Higher user volumes or growing transaction throughput change the calculation: the SaaS recurring cost continues to grow while the custom asset remains fully owned at no incremental license fee.3
The CEO question is not which approach is cheaper today. It is which approach is cheaper across the application's productive life, given the specific business volume, integration scope, and compliance requirements. The honest answer depends on the audit, not on the brochure.
What hidden costs do CEOs underestimate when evaluating SaaS?
The SaaS license fee is the visible cost. Several hidden costs accumulate alongside it, and CEOs who budget only the license miss the real comparison against custom development. Four hidden costs recur across mid-market SaaS evaluations.
Integration cost is the first hidden component. When the business runs multiple SaaS platforms, each one needs to exchange data with the others to avoid manual re-entry. Some platforms provide native integrations, but the most useful integrations frequently require middleware platforms like Zapier, MuleSoft, or custom-built connectors. The middleware carries its own monthly fee, and the connectors require ongoing maintenance as either platform updates its API.
Customization workaround cost is the second hidden component. When the SaaS product does not match the business workflow exactly, staff develop workarounds: spreadsheets that hold data the SaaS does not capture, side processes that compensate for missing functionality, and manual approval workflows that bypass the platform's standard logic. The labor cost of these workarounds is invisible in the SaaS budget line but appears in productivity loss that CEOs notice without attributing to the cause.
Data lock-in cost is the third hidden component. SaaS vendors structure their terms of service to retain ownership and control of the data stored in their platforms. When the business decides to migrate away from a SaaS product, the export process is often incomplete, the data formats are proprietary, and the historical context that gave the data meaning is lost. The cost of recovering the business's own data from a SaaS platform exit can equal years of license fees.4
Vendor pricing risk is the fourth hidden component. SaaS vendors raise prices regularly, and the business has limited recourse once it has built operational dependence on the platform. A SaaS subscription that was economical at the original price may not remain economical after three or four annual price increases. The cost of switching to a different SaaS product, or to custom development, must be weighed against the cumulative cost of remaining on the original platform under its updated pricing.
Speak directly with the engineer who would scope your buy-or-build assessment
A free 30-minute consultation to evaluate whether SaaS or custom .NET is the right path for your business. No obligation, no sales handoff.
How does data sovereignty factor into the decision?
Data sovereignty is the fourth situation where custom .NET beats SaaS, and the only one where SaaS is excluded by the underlying requirement rather than out-economized over time. Businesses operating under specific regulatory frameworks, contractual obligations to large customers, or legal exposure that requires controlled data location cannot use SaaS for the affected business functions regardless of how favorable the pricing or integration is.
Three categories of business face this constraint regularly. The first is businesses operating under federal compliance frameworks that require data to reside on infrastructure controlled by the business, including specific government contracting requirements, defense-related obligations, and federally-regulated industries with strict data handling rules. A second category is businesses serving large enterprise customers whose security review processes prohibit vendor relationships that involve customer data passing through shared cloud platforms. Jurisdictions with data residency laws form the third category: those laws require specific physical storage locations for particular categories of data, which excludes shared cloud SaaS by definition.3
Custom .NET deployment supports all three scenarios because the deployment location is a buyer decision. The application can run on a Windows server in the buyer's facility, in a private hosting environment dedicated to the buyer, or on cloud infrastructure configured to meet the specific sovereignty requirements. SaaS architectures, which depend on shared cloud platforms operated by the vendor, do not provide that flexibility. The CEO who has data sovereignty as a constraint does not have a choice between SaaS and custom. That choice has already been made by the regulatory or contractual requirement.
What does the buy-or-build assessment actually look like at PCG?
PCG performs a buy-or-build assessment as a defined engagement designed to produce a CEO-grade decision document. The assessment is platform-neutral. When SaaS is the right answer, PCG recommends SaaS and identifies the specific products to evaluate. When custom is the right answer, PCG quotes the fixed-price engagement after the source audit. The assessment is the deliverable, not a sales pitch for custom development.
What the assessment evaluates
Buy-or-build inputs
- Current SaaS portfolio inventory and license costs
- Integration burden between SaaS platforms
- Business logic specificity against vendor templates
- User volume and projected growth trajectory
- Data sovereignty and compliance requirements
- Staff time spent on workarounds and manual processes
What the assessment delivers
Written CEO decision document
- Platform-neutral recommendation with reasoning
- SaaS product short-list if SaaS is the right answer
- Custom .NET scope and approach if custom is the right answer
- Identified hybrid options where mixed approach fits
- Multi-year cost comparison framework
- Migration pathway if existing SaaS is being replaced
The assessment phase typically completes in 2 to 4 weeks. The CEO ends the engagement owning a decision document the business uses regardless of which path is chosen.
PCG's approach to the assessment reflects 31 years of running custom software projects and recommending against custom development whenever SaaS would solve the problem. The platform-neutral framing is not marketing positioning. It is operationally how PCG has filtered engagements since 1995, because committing to a custom build that should have been a SaaS purchase produces a project that disappoints the buyer and damages the consultancy's reputation. Both outcomes are worse than recommending SaaS when SaaS is the right answer.1
Can a business start with SaaS and migrate to custom later?
Yes, and most businesses that end up on custom .NET arrived there through this path. The sequence is common enough that PCG treats it as the default expectation: businesses start with SaaS when their operational requirements are still emerging, encounter the specific situations where SaaS no longer fits, and migrate to custom when the case becomes clear. Migration is a defined engagement, and the SaaS data moves with the business rather than being abandoned.4
The transition typically happens in one of three patterns. The first pattern is replacement: a single custom .NET application replaces a single SaaS subscription that no longer fits. Consolidation is the second pattern: a single custom .NET application replaces three to five SaaS subscriptions that were purchased to cover gaps in each other, with the consolidation eliminating both license fees and integration burden. Hybrid is the third pattern: custom .NET handles the business-specific operations while SaaS continues to handle standard functions like email, accounting, or HR.
Each pattern carries different scope, timeline, and complexity. PCG's source audit determines which pattern fits the business and quotes the migration accordingly. The audit also identifies whether the migration should happen now, in phases, or be deferred until specific operational triggers occur. CEOs end the audit with a documented transition plan rather than a binary commit-now-or-not decision. That documented plan is itself a planning asset the business uses regardless of which path is ultimately chosen.
Find out whether SaaS or custom .NET fits your situation
A free 30-minute consultation, followed by a fixed-fee buy-or-build assessment if it is the right next step.
SaaS is almost always less expensive in the first 12 to 18 months because it carries no upfront development cost. The comparison changes after the third year as license fees compound while a custom asset is fully paid off. The crossover point depends on the specific business volume, the integration scope, and how often the SaaS vendor raises prices. PCG's source audit determines where the crossover falls for each business rather than relying on generic claims from either side of the debate.
Yes. Custom .NET applications frequently replace three to five SaaS subscriptions that were originally purchased to cover gaps in each other. PCG's source audit identifies the actual business functions performed across the existing SaaS portfolio and designs a single custom application that performs those functions in one working environment. The consolidation eliminates per-subscription license fees and removes the integration burden between previously disconnected SaaS platforms.
PCG migrates SaaS data into the custom .NET application as part of the build engagement. Each SaaS platform's data export is mapped to the destination schema, cleaned for quality issues identified during the audit, and loaded with reconciliation confirming that what left the source arrived at the destination. The buyer ends the migration owning the historical data outright, which is rarely the case under SaaS terms of service.
The decision typically takes 2 to 4 weeks once the source audit is underway. PCG's audit produces a written assessment of which SaaS platforms the business currently runs, what gaps drove their selection, what integration costs are accumulating between them, and where the custom .NET path produces a measurable improvement. The audit stands on its own as a planning document regardless of the final decision.
Yes. PCG performs a buy-or-build assessment that maps the business requirements against both SaaS and custom .NET options. The assessment is platform-neutral. When SaaS is the right answer, PCG recommends SaaS and identifies the specific products to evaluate. When custom is the right answer, PCG quotes the fixed-price engagement after the source audit. The assessment is the deliverable, not a sales pitch for custom development.
1 Phoenix Consultants Group, Custom .NET Software Development for Mid-Sized Business. phxconsultants.com
2 Phoenix Consultants Group, Custom .NET Software Development service page. phxconsultants.com
3 Phoenix Consultants Group, What Drives Custom Software Migration Cost. phxconsultants.com
4 Phoenix Consultants Group, The Cost of Losing Your Business Software Source Code. phxconsultants.com
This article is informational and reflects PCG's experience building custom .NET applications and advising on SaaS-versus-custom decisions since 1995. It is not legal, regulatory, financial, or procurement advice for any specific situation. For guidance tailored to a particular buy-or-build evaluation, contact Phoenix Consultants Group directly. PCG was founded in 1995.