Deployment and Ownership

Own the systems that matter

The question isn't cloud or on-premise. Nearly every established company runs both today, and the honest starting point for most is a mixed one. The real question is direction: which workloads are moving inside your perimeter over time, and which are genuinely better left outside. Our view, stated plainly: the more a system matters to your business, the more you should own it. Companies that get serious about AI tend to end up running it themselves, because the data is theirs, the decisions have consequences, and the costs scale with success. That's the direction of travel we see. But almost nobody gets there in one move, and a few workloads shouldn't move at all. We build for wherever you actually are, and we'll tell you when staying put is the right call.

How We Deliver

Everything we build runs on your infrastructure. Your cloud account, your data center, your private cloud: your choice, but always yours. We don't host anything on your behalf, and we don't sell a hosted tier. There's no Grit-operated environment your data passes through, because there is no Grit-operated environment. Built on open-source foundations, delivered as code you own outright. If you stopped working with us tomorrow, the systems keep running and your team can keep changing them. Ongoing support is a retainer, not a subscription. Most clients keep us on monthly for maintenance, updates, and new work. That fee buys engineering time. It isn't a licence, and it isn't what keeps your systems running. If you ended the engagement tomorrow, everything we've built continues to operate on your infrastructure. You'd be losing a development partner, not access to your software. When we say your stack is mixed, we mean your stack, not ours. Most companies use third-party vendors for some things, such as payroll, CRM, and payment processing, and that's usually correct. Those relationships are yours, and we integrate with them where it makes sense. The distinction is that we're never one of them.

Drawing the Line

Workload	Where it usually belongs	The governing reason
Card payment processing	Third-party processor	Tokenization keeps cardholder data out of your environment and materially reduces PCI DSS scope. Bringing this in-house increases your risk, not theirs.
CRM, HR, payroll, collaboration	Third-party vendor	Commodity functions with low regulatory weight. Rarely worth the cost of operating yourself.
Books of record (ledger, ERP, financial close)	Your environment	Audit and control boundaries. You need to evidence configuration changes and segregation of duties in a system you administer.
Customer and employee PII	Your environment	Data residency rules and cross-border transfer restrictions constrain where records can physically sit.
Proprietary operational data	Your environment	Your process data, designs, client files, and internal knowledge are the asset. They should not become someone else's training corpus.
Decision-making AI models	Your environment	Reproducibility. If a hosted model changes underneath you, a decision you made last quarter may no longer be explainable.
Internal AI agents over company data	Your environment	The agent is only as valuable as the corpus behind it, and the corpus is the part that can't leave.
Document processing and OCR	Depends on classification	Fine with a vendor for public material. Not for client files, contracts, or anything identifying.

How Far You Take It

This is about your stack overall, not about how we deliver. Our side of it is the same at every stage: built on your infrastructure, owned by you.

• Vendor-heavy - Most functions with third-party providers. Correct when you're small, when nothing you handle is especially sensitive, and when nobody on your team wants to own uptime. If this describes you, keep using the tools you have. You'll know when that stops working.
• Mixed - Commodity functions stay with vendors, while the data that matters and the systems that make decisions come in-house. This is where most of our engagements start, and it's a legitimate place to stop. The engineering here is mostly at the boundary: clean interfaces, logged data flows, and a documented exit path for every external dependency.
• Fully in-house - Your infrastructure, your models, your code, with outside dependencies limited to the few that genuinely belong there, payment processing being the clearest example. Fixed costs, no roadmap you don't control, nothing leaving your network. This is where companies land when AI stops being an experiment and becomes how the business runs.

Most clients move down this list over time. We build the first stage so the next one is a migration rather than a rewrite.

Four Constraints That Set the Boundary

• Regulatory and contractual obligation - Data residency rules, retention schedules, audit access rights, and commitments you've made in your own customer contracts determine where certain records can sit. Third-party risk frameworks have also raised the bar on concentration and exit planning. The question is increasingly not just whether a vendor is secure, but whether you could leave one.
• Model governance - This is where AI diverges sharply from ordinary software. If you need to explain why a system made a particular decision, whether to an auditor, a regulator, a client, or a court, you need the model version that made it. Hosted providers deprecate and update model versions on their own schedule, often without a path back to prior behavior. For any agent touching decisions that carry consequences, version control over the model is a governance requirement rather than a preference.
• Cost predictability - Usage-based AI pricing scales with success. An agent that works gets used, and token spend grows fastest in exactly the quarter you were hoping to show efficiency gains. Fixed infrastructure converts an unbounded variable into a capacity plan.
• Concentration and continuity - If a critical process depends entirely on a single external provider, that dependency is itself a risk. The ability to run a workload in your own environment, even if you choose not to today, is what turns an exit plan from a document into a capability.

By Industry

• Financial Services - The line here is drawn by supervision. Payment rails belong with third-party processors, and pushing card data out of your environment is the correct architecture rather than a compromise. But the general ledger, KYC and AML records, credit decisioning, and any model touching suitability or surveillance sit inside the perimeter, because examiners expect access, reproducibility, and change control you can evidence. The integration layer between the two is where most of the engineering lives, and where most of the documentation is missing.
• Wealth Management - Client holdings, communications, and planning documents are among the most sensitive data any firm holds, and much of it is retained under recordkeeping rules for years. AI agents that draft client communications, summarize portfolio positions, or surface suitability considerations need to run over that corpus without it leaving your control. The corpus is also the differentiator: your firm's research, positioning, and client history is precisely what a general-purpose hosted tool doesn't have.
• Manufacturing Process - data, tolerances, yield curves, and supplier terms are trade secrets in the most literal sense. Plant-floor systems also carry a latency and availability requirement that a dependency on external connectivity doesn't serve well. A line shouldn't stop because a link went down. Meanwhile the commercial layer above it, from CRM to procurement, is usually fine with vendors. The interesting work is the boundary between OT and IT.
• Professional Services - Client confidentiality and privilege are contractual and sometimes legal obligations, and many client agreements now explicitly restrict where work product may be processed. Firms want AI over their own matter files, engagement history, and accumulated expertise, which is exactly the material they've promised to keep contained. Running those agents internally is what makes it possible to use the data at all. Technology The usual driver here is economics rather than regulation. Hosted infrastructure is the right call early and stays right for a long time, but per-seat and per-token pricing eventually crosses over, particularly once an AI feature ships to your own customers and your unit costs are tied to someone else's price list. Owning the inference layer turns a variable cost-of-goods into a fixed one, and removes a roadmap dependency from your product.

What We Do

• Deployment assessment - We map your current workloads against data sensitivity and regulatory obligation, and identify where the line is drawn incorrectly in either direction: sensitive data sitting with a vendor, or commodity functions being operated at unnecessary cost.
• AI agents built for your environment - Deployed on your infrastructure, with model version control, decision audit trails, and no proprietary data leaving your network. Built on open-source foundations so you retain full ownership and can evolve the system on your terms.
• Custom software and integration - Core system and ERP work, the integration layer between in-house and third-party systems, and the migration path when a workload needs to move.
• One delivery model, applied to your situation We only build systems that run on your infrastructure. That part isn't variable. What varies is scope: which workloads come in-house now, which stay with vendors, and in what order. Where an outside provider is genuinely the better answer, as with payment processing, we'll say so and integrate against it rather than rebuild it.