Build vs Buy a Software Factory: How Platform Teams Should Make This Decision

Key takeaways

• A demo can work because its author fills in the gaps. The build estimate needs to cover what happens when other teams use it without that help.
• Buying a shared platform still leaves your team in charge of its delivery process, standards, and custom workflows.
• Buying agents and wiring them together yourself still leaves you with a platform to maintain. Include that work when comparing the options.

Let’s say you give a coding agent a dependency-upgrade ticket. At the end, it will open a pull request. But if someone still has to find the reviewer, chase the approval, and arrange the deployment, we've left much of the job with the same people as before. We can do so much better than this if we apply software factory principles to the problem.

Reimagining that same ticket going through aprocess  calling agents and existing pipelines to move a change through review, deployment, and health checks. It looks up who owns the service and stops for human approval where you've required it. If we extrapolate that flow across a large team, suddenly there’s a need for a scaled, governed approach. We call this a software factory. It’s the future of software development, but like all things in software, it leaves you with a major decision. Should you build it or buy it? What are the risks and trade-offs to each approach? 

Let’s break it down.

Demos used to look like demos. Now they appear finished, and it’s not a good thing

A two-week demo used to look unfinished: they would often have hardcoded service names, or one integration that sort of worked and two that were commented out, plus an error handler that printed a stack trace and gave up. You could see the holes from across the room. Now the same two-week build gets you slick loading states and a passing test suite, and it handles every case the person building it thought to try. The holes are in the same places. But you can't see them from across the room anymore.

So we take the two weeks it took to build the demo and use that to estimate a platform for the whole company. We haven't yet handed it to another team, let alone checked what happens when their approval rules don't match ours.

Maintaining that shared infrastructure was expensive before agents entered the picture. At GitHub, adding one new resource type used to  take three to four months.Three to four months, at a company that ships developer tooling for a living. Their VP of Engineering, Meirav Feiler, explained the decision to buy, and not build: "It's not our main focus." GitHub is a Port customer now, which is how I have the quote, and exactly why you should check the link yourself.

What are you signing up to build?

Let’s return to our original example. An engineer can easily wire Claude Code into CI and get a dependency update working. In the demo, that engineer can manually pick the repository, supply credentials, and restart the job when it gets stuck. Other teams will expect the software to do those things.

1. Integrations × 10+. A working demo usually connects to one repository and one ticket tracker using hardcoded secrets or personal tokens. A production software factory must continuously sync across Jira, GitHub/GitLab, PagerDuty, CI/CD runners, Kubernetes clusters, and cloud providers. Every API deprecation, schema update, rate limit, and webhook failure becomes an incident your platform team has to debug and patch forever.
2. Data model & schema. Agents are only as good as the context they receive. Without a unified service catalog and dynamic graph model, an agent doesn't know which service owns a repo, which team owns that service, or what tier of criticality it carries. Building and schema-versioning this catalog—and keeping it accurate through organizational re-orgs and service renames—is a massive ongoing platform investment.
3. On-behalf-of RBAC. Reusing the demo author's personal access token gives every automated job broad admin rights—a security disaster waiting to happen. You must design granular identity propagation so agents act strictly on behalf of the requesting user or service account, enforcing enterprise permission boundaries at every step of execution without leaking secrets.
4. Self-service actions & workflows. Developers need intuitive UI inputs, state validation, asynchronous step handling, human-in-the-loop approval gates, and reliable retry logic. When a multi-step deployment times out midway, blindly retrying can cause duplicate resource creation or partial outages. Implementing idempotent operations and safe rollback mechanisms requires significant workflow engine engineering; see AWS's guidance on safe retries to appreciate the complexity involved.
5. Agentic API & MCP. Autonomous agents need programmatic interfaces and Model Context Protocol (MCP) tool bindings to discover resources and trigger platform tasks on their own. You will need to build, document, and maintain secure, typed APIs with strict input validation and meaningful error messages explicitly engineered for LLM consumption.
6. Agent registry & governance. Allowing arbitrary AI agents to run wild across production codebases creates severe operational risks. You need a centralized agent registry to manage versioning, scoping, guardrails, and compliance checks. Every model upgrade or prompt revision requires rigorous evaluation suites—refer to Anthropic's guide on evals for AI agents—to prove the agent won't hallucinate destructive commands or skip required approval steps.
7. GitOps pipeline. The software factory itself must be declared as code. Platform configurations, blueprint schemas, and workflow routines need continuous integration, testing, peer review, and automated promotion pipelines. A single unvalidated change to a factory workflow can break software delivery for the entire engineering organization.
8. Observability & cost control. When an agent-driven deployment fails at 2:00 AM, engineers need end-to-end tracing that correlates agent transcripts, prompt tokens, git commits, and pipeline logs. Furthermore, unconstrained AI agents trapped in infinite retry loops can burn through thousands of dollars in inference costs overnight unless you build automated rate-limiting, circuit breakers, and cost-budget alerts.
9. Multi-environment. Managing workflows across development, staging, sandbox, and production environments demands isolated credentials, variable scoping, and context-aware routing. The factory must guarantee that an agent testing a dependency patch in dev cannot accidentally mutate production infrastructure or access restricted production secrets.
10. Adoption & on-call ops · forever. Building the platform is only the beginning. Once hundreds of developers rely on the factory for their daily work, your platform team becomes an internal service provider handling developer onboarding, writing documentation, triaging broken runs, and running a 24/7 on-call rotation to keep the internal delivery pipeline alive.

Starting with Backstage or an existing internal platform can cover some of these items.

What buying actually means

For most platform teams, I'd buy the shared platform and build the workflows specific to the business. And yes, I sell shovels (BTW, you need a shovel), I work for Port, a platform vendor.

Gartner's September 2026 Innovation Insight: AI Software Factories distinguishes assembling a factory yourself, buying an integrated factory product, and building on an agentic engineering platform. It puts Port in the third group. I include that route under "buy" because you're paying a vendor to maintain the shared platform while your team writes its workflows.

The report also says no vendor yet sells a complete factory you can plug in and run. Gartner recommends choosing according to your existing tools, the controls you need, and what your team can build and operate.

A quote for platform engineering tools should include what you'll pay as agents run more jobs. I would add your team's time for configuration and custom integrations to that number, along with maintaining evaluations for your codebase.

But what about flexibility?

You'll want several workflows, with different shapes. Dependency updates might need an owner's review; incident response could involve a diagnostic agent, a proposed fix, and approval before remediation. Buying a product with fixed processes would constrain those choices. I understand wanting to write your own.

Rigid platforms are familiar. Their name is Legion, for they are many. But the history of platforms has a useful exception: the internal developer portal. Its flexibility isn't Spotify doing us a favor by giving up control of a locked-down platform (exceptionally benevolent as they may have been). An IDP can't do its job unless it adapts to the organization using it. Its catalog must represent your resources and relationships; self-service workflows have to fit your tools and approval rules. Otherwise, your engineers keep working around it.

‍

Port is the Agentic SDLC Platform. We built it on the configurable data model and workflows from our IDP, so the move to agents doesn't require you to fit your organization into a fixed delivery process.

‍

 Our Context Lake brings data from your tools together with business context such as service criticality and customer commitments. In blueprints, you define those resources and relationships yourself: one service can have several owners and a relation to every customer it serves. Workflows branch on that context, so a change can take a different approval path depending on the customer it affects, and the same workflow can invoke agents or your existing pipelines.

dLocal wrote their own agent, dCoder, on top of the Context Lake. Their 400 engineers move cross-border payments, and dCoder now takes 45% of their engineering tickets end to end. Alberto Almeida, dLocal's CTO, calls end-to-end agentic coverage "the single metric I care about the most."

Keeping the Context Lake data accurate is still your work, and a workflow that needs an unsupported execution environment will need an integration or a different purchase.

When building makes sense

If you’ve heard about Tessl, the AI tooling company, and their own software factory, you might ask -  If they can do it, why shouldn't your team?

You're probably not Tessl, though. They already have the AI infrastructure and engineers who specialize in this work. Building the factory can also teach them things about context and evaluation that feed back into the products they sell. That's a reason to build beyond automating their own delivery, and I'd want to know what our equivalent was before committing a team to it.

Put the decision in front of leadership

Bring one workflow, its target outcome, and its deadline. Compare a year of operation on both paths, including integration work and the engineers diverted from other projects. An internal demo estimate and a vendor's production proposal describe different scopes.

Then run the awkward cases in a pilot. Make us handle a missing owner and a rejected approval. Interrupt execution after a change lands, and check whether the workflow can establish what happened before retrying. Record the human intervention and total cost per completed, accepted change, including failed attempts, and watch the review queue: if it grows, you've moved the bottleneck to reviewers.

The proposal should name who operates each part and which requirements remain unproven. Give leadership that evidence alongside the cost of another quarter of manual patching.

FAQ

What if we already have agents and pipelines that work?

Keep them in the evaluation. Port connects to external agents and invokes existing execution systems. Test the actual integration with your agent, including credentials and failure reporting. Cataloging an agent alone doesn't control everything it can do outside the workflow, so establish where enforcement happens.

How do we price a build when the demo already works?

Have another team try it without its author helping, and write down every place they get stuck. Estimate the work to fix those gaps with the engineers who will do it. Add a year of maintenance, accounting for the parts your existing platform already handles, before comparing with a vendor's offer.

How do we limit vendor lock-in?

Keep custom logic and evaluations versioned outside the platform where practical. During evaluation, export a workflow's configuration and try replacing one component, checking what happens to approval history, permissions, and run state. An API makes access possible; it doesn't establish how much behavior you'll need to rebuild.

What if the internal build keeps slipping?

Set a checkpoint for one workflow handling real work before funding the next expansion. If it slips, price the remaining work again, including recovery tests and operating coverage, and compare that estimate with a vendor pilot. You can keep useful agents and integrations even if you abandon the platform build.

Argue about it at PortCon

If you'd rather have this argument in person, come to PortCon, Port's Agentic SDLC Summit, in San Francisco on November 17-18, 2026. Bring the workflow you're deciding whether to build.