Is Your IT Team Ready to Build with AI?

Here's how Fullscript's IT team replaces SaaS tools with internal apps of our own.

Back to IT

Our director, Daniel Valois, wrote the first Builder's Corner post from IT about designing warehouse networks for the failure case. This one is about software, which is a little unusual for an IT team.

Traditionally, IT buys software, sets it up, and supports it. Writing it was someone else's job. Like most companies, we followed a simple rule: if a tool wasn't part of our core competency as a business, we bought it. That rule made sense when building software was slow and expensive.

That's changing, and we've increasingly started building internal apps to replace some of the SaaS tools we used to buy.

Everyone can build now

Our company hackathon just wrapped, and a lot of what was built was working software made by people who don't write code for a living. That's a good thing. AI agents have made it possible for almost anyone to turn an idea into something that runs.

Here's the catch. You now have to run your software, and consider everything around it:

Who can sign in, and what can they see once they're in?
When it breaks at 2 a.m., who finds out?
Who fixes it when the person who built it is on vacation, or has moved teams?
A year from now, is it still patched? Does anyone remember it exists?

When those questions don't have good answers, a tool ends up in one of two places. It stays a demo forever, or it quietly goes into production with a personal API key, a shared password, and no logs.

Our Security team put it well in a recent newsletter. Hackathon week is a pop-up kitchen, and they want us cooking in one that would pass inspection, "so that if your dish earns a permanent spot on the menu, nobody has to rebuild it from scratch first."

That's the idea behind this post. Build the kitchen once, and every dish after that starts in a kitchen that passes inspection.

IT at a software company

Fullscript is a technology company at heart, and for an IT team, that's a big advantage. We sit alongside engineers who build and run software for a living, and over the years, we've learned a lot from them: how to review changes, how to ship safely, and how to own what you build after it launches.

As Fullscript's IT team invested time creating ways to deploy, host, secure, scale, and monitor software, we had an existing framework to leverage AI coding agents.

The Stack

Your identity provider

An identity provider (IdP) is crucial for securing access to your application. When every app signs in through single sign-on (SSO), you get one place to enforce MFA and access policies, one audit trail, and a clean joiner-mover-leaver process.

To get the most out of it:

Use group-based access. Apps read roles from IdP groups instead of keeping their own user tables, so user management is centralized in one place.
Manage the IdP as code. Apps, groups, and assignments should live in an infrastructure-as-code tool such as Terraform, so every access change is reviewed and has history.

A zero trust front door

At Fullscript, our internal apps sit behind Cloudflare's zero trust network access (ZTNA), sometimes called an identity-aware proxy, so every request is checked against our IdP before it reaches the app. Cloudflare Access, Zscaler Private Access, Tailscale, and Google's Identity-Aware Proxy all fill this role. This means a new app is protected from the day it launches. It is behind the same front door as everything else, which makes shipping both faster and safer.

Golden paths for deploying

Platform engineering at Fullscript has developed golden paths: supported, pre-approved ways to build, deploy, and scale an app. Ideally, you want more than one, because apps come in different shapes:

An app platform for full web apps with a database and scheduled jobs. At Fullscript, our Platform Engineering team built "Legoland," a set of shared Helm charts on Kubernetes.
Serverless functions, like AWS Lambda or Azure Functions, for small, event-driven jobs.
Simple or edge hosting for internal pages and lightweight apps, from static hosting to edge runtimes like Cloudflare Workers, Netlify Edge Functions, or Fastly Compute.
Workflow automation for connecting tools you already have without building a full app. Fullscript has been building incredible tools and automations in n8n. Zapier, Make, Workato, and Microsoft Power Automate fill the same role.

Behind every path, shared CI/CD templates should build the app, preview changes before they apply, and deploy with short-lived credentials instead of long-lived keys.

Secrets

Secrets belong in a secrets manager, such as AWS Secrets Manager, HashiCorp Vault, or 1Password, and get injected at runtime. They should never be committed to a repo or left in a .env file on a laptop.

At Fullscript, our developer tooling lets anyone add a secret to our secrets manager through a merge request. The secret is encrypted before it's committed, the change gets reviewed, and the secret lands where it belongs. When people are building faster than ever, the safe way to handle a secret is also the easy way, so nobody needs to hardcode a key just to get a demo working.

Observability and on-call, built in

Every app needs centralized logging, metrics and uptime checks, and an incident management tool that routes alerts to an on-call owner. Observability platforms like Datadog, Grafana, New Relic, and Coralogix, as well as incident management tools like incident.io or PagerDuty, are all good options, and plenty of others do the job. Whatever you choose, make it the default. Adding monitoring to a new app should take a few lines of config, and setting up alerts should be just as easy.

Infrastructure as code for everything around the app

Manage the systems around your apps, like your IdP, DNS, access policies, and SaaS settings, as infrastructure as code with a tool like Terraform, OpenTofu, or Pulumi, and change them through merge requests. When a new app needs SSO, access rules, and a hostname, it's a reviewed change with history, not clicks in an admin console that nobody remembers a year later.

Give your AI agents the rules

An agent can build an app in an afternoon, but it doesn't know your conventions unless you tell it. Here are two things that can help:

A shared skills library of rules and skills files that teach coding agents your standards. Ours is called Nova, and it is automatically added for users in their environment.
A governed AI gateway for models and company data, with role-based access and PII and PHI redaction built in. Fullscript leverages shared LLM gateways and EKG, our internally developed MCP gateway.

Review: People and AI

Every change should go through code review by a person and an AI reviewer. At Fullscript we use Nitro, an agentic developer our engineering team built in-house. Tagging Nitro on a merge request will trigger it to leave inline feedback on conventions, performance, and security, or assign it an issue and it opens a merge request of its own. However, it doesn't replace people. Every change still needs a human approval and passing tests, but when the team ran Nitro against old merge requests that had caused production issues, it caught the bugs people missed, and that's exactly the kind of second set of eyes a team benefits from.

What consistency buys us

The biggest win here isn't speed. It's that our apps are consistent where it matters, even when they're built differently. A full web app on the app platform and a one-page site on simple hosting look nothing alike, but underneath they sign in, keep secrets, and get reviewed the same way.

Same sign-in. Same front door. Same secrets pattern. Same monitoring. Same review. When Security looks at something IT built, they can expect secure patterns and practices. When someone new joins IT, they aren't reverse-engineering a one-off solution. And when the shared foundation gets better, every app on it gets better too.

Building isn't the compromise anymore

Once the foundation is shared, building stops being the scrappy option. For a lot of problems, it's the better one.

It fits our process, not the average customer's.
Integrations don't wait on a vendor's roadmap.
Changes ship in days, not quarters.
The data stays with us.
No per-seat pricing.

Nothing is an automatic buy anymore

Not long ago, IT's build list was short: scripts, small integrations, the odd internal page. Anything bigger was likely a buy. That's changed, and we've changed how we look at tools IT has always bought.

That doesn't mean we'll build all of them. It means each one gets a real comparison instead of a default answer. Before we decide, we ask:

How well does it fit? How much of the vendor's product would we use, and how much of our process would we bend to match it?
What does it cost over a few years? Licenses and seats on one side. Building it, running it, and improving it on the other.
Who owns it a year from now? Someone has to keep it running, patched, and getting better after launch.
What happens when it's down? The more the business depends on it, the higher the bar.
Does it fit our toolbox? Can we build, deploy, and support on a path we already have?

Sometimes buying still wins. However, the answer isn't automatic anymore, and that's the change.

Building still means owning, and we try to be honest about that. The foundation makes ownership cheaper. It doesn't make it free.

If you're weighing build vs. buy

If you're in IT and building is starting to look possible, start with the foundation, not the app. Solve sign-in, access, secrets, deploys, and monitoring once, and make them the default. Then every tool you build after that starts on day two, instead of day zero.

If your IT team sits inside a tech company, look around first. The foundation may already exist, and the engineers who built it are probably happy to show you how it works.

Don't build for the demo. Build for day two.